]> granicus.if.org Git - postgresql/commitdiff
Relax overly strict assertion
authorAlvaro Herrera <alvherre@alvh.no-ip.org>
Tue, 12 Feb 2019 21:42:37 +0000 (18:42 -0300)
committerAlvaro Herrera <alvherre@alvh.no-ip.org>
Tue, 12 Feb 2019 21:42:37 +0000 (18:42 -0300)
Ever since its birth, ReorderBufferBuildTupleCidHash() has contained an
assertion that a catalog tuple cannot change Cmax after acquiring one.  But
that's wrong: if a subtransaction executes DDL that affects that catalog
tuple, and later aborts and another DDL affects the same tuple, it will
change Cmax.  Relax the assertion to merely verify that the Cmax remains
valid and monotonically increasing, instead.

Add a test that tickles the relevant code.

Diagnosed by, and initial patch submitted by: Arseny Sher
Co-authored-by: Arseny Sher
Discussion: https://postgr.es/m/874l9p8hyw.fsf@ars-thinkpad

contrib/test_decoding/expected/ddl.out
contrib/test_decoding/sql/ddl.sql
src/backend/replication/logical/reorderbuffer.c

index bd9b42f40106d8e50dcc21beeaab8426a41f6ed2..2690dbc47b64e49c93ae7d56ba2842425293c947 100644 (file)
@@ -405,6 +405,24 @@ SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'inc
  COMMIT
 (6 rows)
 
+-- check that DDL in aborted subtransactions handled correctly
+CREATE TABLE tr_sub_ddl(data int);
+BEGIN;
+SAVEPOINT a;
+ALTER TABLE tr_sub_ddl ALTER COLUMN data TYPE text;
+INSERT INTO tr_sub_ddl VALUES ('blah-blah');
+ROLLBACK TO SAVEPOINT a;
+ALTER TABLE tr_sub_ddl ALTER COLUMN data TYPE bigint;
+INSERT INTO tr_sub_ddl VALUES(43);
+COMMIT;
+SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1');
+                       data                       
+--------------------------------------------------
+ BEGIN
+ table public.tr_sub_ddl: INSERT: data[bigint]:43
+ COMMIT
+(3 rows)
+
 /*
  * Check whether treating a table as a catalog table works somewhat
  */
index e99b2d37d9eb3ff3e59299f958188e4cd5661a3c..2ee22dd8330d0f322bae2be6cec68437d5b1700b 100644 (file)
@@ -235,6 +235,19 @@ INSERT INTO tr_sub(path) VALUES ('5-top-1-#1');
 COMMIT;
 
 
+SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1');
+
+-- check that DDL in aborted subtransactions handled correctly
+CREATE TABLE tr_sub_ddl(data int);
+BEGIN;
+SAVEPOINT a;
+ALTER TABLE tr_sub_ddl ALTER COLUMN data TYPE text;
+INSERT INTO tr_sub_ddl VALUES ('blah-blah');
+ROLLBACK TO SAVEPOINT a;
+ALTER TABLE tr_sub_ddl ALTER COLUMN data TYPE bigint;
+INSERT INTO tr_sub_ddl VALUES(43);
+COMMIT;
+
 SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1');
 
 
index f6ea315422636c4a4cb1884ed07400291721c7b6..d147735ce7431a95f5a38ff15d393afdd85c7986 100644 (file)
@@ -1387,15 +1387,19 @@ ReorderBufferBuildTupleCidHash(ReorderBuffer *rb, ReorderBufferTXN *txn)
                }
                else
                {
+                       /*
+                        * Maybe we already saw this tuple before in this transaction,
+                        * but if so it must have the same cmin.
+                        */
                        Assert(ent->cmin == change->data.tuplecid.cmin);
-                       Assert(ent->cmax == InvalidCommandId ||
-                                  ent->cmax == change->data.tuplecid.cmax);
 
                        /*
-                        * if the tuple got valid in this transaction and now got deleted
-                        * we already have a valid cmin stored. The cmax will be
-                        * InvalidCommandId though.
+                        * cmax may be initially invalid, but once set it can only grow,
+                        * and never become invalid again.
                         */
+                       Assert((ent->cmax == InvalidCommandId) ||
+                                  ((change->data.tuplecid.cmax != InvalidCommandId) &&
+                                       (change->data.tuplecid.cmax > ent->cmax)));
                        ent->cmax = change->data.tuplecid.cmax;
                }
        }