Accept regression diffs in the sequence test case
authorPavan Deolasee <[email protected]>
Fri, 17 Aug 2018 09:53:33 +0000 (15:23 +0530)
committerPavan Deolasee <[email protected]>
Fri, 17 Aug 2018 09:53:33 +0000 (15:23 +0530)
These diffs are on the account of differences in the way we handle WAL logging
and sequences on the coordinator. There is scope for improvement here from
usability perspective, but these are not regressions from the past behaviour.

src/test/regress/expected/sequence.out
src/test/regress/sql/sequence.sql

index dd065a3f3561cb230ab2a8ea4c8d611609d6d3ae..348db8ce2d5b5da32197598dc504907585678779 100644 (file)
@@ -262,10 +262,12 @@ SELECT nextval('foo_seq_new');
 
 -- log_cnt can be higher if there is a checkpoint just at the right
 -- time, so just test for the expected range
+-- In XL, since we WAL log the same count as received from the GTM, log_cnt is
+-- usually just 1 (unless it increases exponentially)
 SELECT last_value, log_cnt IN (31, 32) AS log_cnt_ok, is_called FROM foo_seq_new;
  last_value | log_cnt_ok | is_called 
 ------------+------------+-----------
-          2 | t          | t
+          2 | f          | t
 (1 row)
 
 DROP SEQUENCE foo_seq_new;
@@ -503,6 +505,8 @@ SELECT * FROM information_schema.sequences
  regression       | public          | serialtest2_f6_seq | bigint    |                64 |                       2 |             0 | 1           | 1                    | 9223372036854775807 | 1         | NO
 (19 rows)
 
+-- In XL, columns such as last_value may not be set correctly on the
+-- coordinator if the nextval was pushed down to the datanode
 SELECT schemaname, sequencename, start_value, min_value, max_value, increment_by, cycle, cache_size, last_value
 FROM pg_sequences
 WHERE sequencename ~ ANY(ARRAY['sequence_test', 'serialtest'])
@@ -522,7 +526,7 @@ WHERE sequencename ~ ANY(ARRAY['sequence_test', 'serialtest'])
  public     | sequence_test7     |           1 |                    1 | 9223372036854775807 |            1 | f     |          1 |           
  public     | sequence_test8     |           1 |                    1 |               20000 |            1 | f     |          1 |           
  public     | sequence_test9     |          -1 |               -32768 |                  -1 |           -1 | f     |          1 |           
- public     | serialtest1_f2_foo |           1 |                    1 |          2147483647 |            1 | f     |          1 |          3
+ public     | serialtest1_f2_foo |           1 |                    1 |          2147483647 |            1 | f     |          1 |           
  public     | serialtest2_f2_seq |           1 |                    1 |          2147483647 |            1 | f     |          1 |          2
  public     | serialtest2_f3_seq |           1 |                    1 |               32767 |            1 | f     |          1 |          2
  public     | serialtest2_f4_seq |           1 |                    1 |               32767 |            1 | f     |          1 |          2
index 98b5c26bd107075bd492f9bb19460cf842560693..cf9989210b6c8977161063168ff6b974ac07cec3 100644 (file)
@@ -138,6 +138,8 @@ SELECT nextval('foo_seq_new');
 SELECT nextval('foo_seq_new');
 -- log_cnt can be higher if there is a checkpoint just at the right
 -- time, so just test for the expected range
+-- In XL, since we WAL log the same count as received from the GTM, log_cnt is
+-- usually just 1 (unless it increases exponentially)
 SELECT last_value, log_cnt IN (31, 32) AS log_cnt_ok, is_called FROM foo_seq_new;
 DROP SEQUENCE foo_seq_new;
 
@@ -238,6 +240,8 @@ SELECT * FROM information_schema.sequences
   WHERE sequence_name ~ ANY(ARRAY['sequence_test', 'serialtest'])
   ORDER BY sequence_name ASC;
 
+-- In XL, columns such as last_value may not be set correctly on the
+-- coordinator if the nextval was pushed down to the datanode
 SELECT schemaname, sequencename, start_value, min_value, max_value, increment_by, cycle, cache_size, last_value
 FROM pg_sequences
 WHERE sequencename ~ ANY(ARRAY['sequence_test', 'serialtest'])