8000 Relax overly strict assertion · postgrespro/postgres_cluster@8c67d29 · GitHub
[go: up one dir, main page]
Skip to content

Commit 8c67d29

Browse files
alvherrealvherre
committed
Relax overly strict assertion
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
1 parent d357a16 commit 8c67d29

File tree

3 files changed

+40
-5
lines changed

3 files changed

+40
-5
lines changed

‎contrib/test_decoding/expected/ddl.out‎

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -409,6 +409,24 @@ SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'inc
409409
COMMIT
410410
(6 rows)
411411

412+
-- check that DDL in aborted subtransactions handled correctly
413+
CREATE TABLE tr_sub_ddl(data int);
414+
BEGIN;
415+
SAVEPOINT a;
416+
ALTER TABLE tr_sub_ddl ALTER COLUMN data TYPE text;
417+
INSERT INTO tr_sub_ddl VALUES ('blah-blah');
418+
ROLLBACK TO SAVEPOINT a;
419+
ALTER TABLE tr_sub_ddl ALTER COLUMN data TYPE bigint;
420+
INSERT INTO tr_sub_ddl VALUES(43);
421+
COMMIT;
422+
SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1');
423+
data
424+
--------------------------------------------------
425+
BEGIN
426+
table public.tr_sub_ddl: INSERT: data[bigint]:43
427+
COMMIT
428+
(3 rows)
429+
412430
/*
413431
* Check whether treating a table as a catalog table works somewhat
414432
*/

‎contrib/test_decoding/sql/ddl.sql‎

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -234,6 +234,19 @@ INSERT INTO tr_sub(path) VALUES ('5-top-1-#1');
234234
COMMIT;
235235

236236

237+
SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1');
238+
239+
-- check that DDL in aborted subtransactions handled correctly
240+
CREATE TABLE tr_sub_ddl(data int);
241+
BEGIN;
242+
SAVEPOINT a;
243+
ALTER TABLE tr_sub_ddl ALTER COLUMN data TYPE text;
244+
INSERT INTO tr_sub_ddl VALUES ('blah-blah');
245+
ROLLBACK TO SAVEPOINT a;
246+
ALTER TABLE tr_sub_ddl ALTER COLUMN data TYPE bigint;
247+
INSERT INTO tr_sub_ddl VALUES(43);
248+
COMMIT;
249+
237250
SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1');
238251

239252

‎src/backend/replication/logical/reorderbuffer.c‎

Lines changed: 9 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1326,15 +1326,19 @@ ReorderBufferBuildTupleCidHash(ReorderBuffer *rb, ReorderBufferTXN *txn)
13261326
}
13271327
else
13281328
{
1329+
/*
1330+
* Maybe we already saw this tuple before in this transaction,
1331+
* but if so it must have the same cmin.
1332+
*/
13291333
Assert(ent->cmin == change->data.tuplecid.cmin);
1330-
Assert(ent->cmax == InvalidCommandId ||
1331-
ent->cmax == change->data.tuplecid.cmax);
13321334

13331335
/*
1334-
* if the tuple got valid in this transaction and now got deleted
1335-
* we already have a valid cmin stored. The cmax will be
1336-
* InvalidCommandId though.
1336+
* cmax may be initially invalid, but once set it can only grow,
1337+
* and never become invalid again.
13371338
*/
1339+
Assert((ent->cmax == InvalidCommandId) ||
1340+
((change->data.tuplecid.cmax != InvalidCommandId) &&
1341+
(change->data.tuplecid.cmax > ent->cmax)));
13381342
ent->cmax = change->data.tuplecid.cmax;
13391343
}
13401344
}

0 commit comments

Comments
 (0)
0