aboutsummaryrefslogtreecommitdiff
path: root/src
diff options
context:
space:
mode:
authorAlvaro Herrera <alvherre@alvh.no-ip.org>2019-02-12 18:42:37 -0300
committerAlvaro Herrera <alvherre@alvh.no-ip.org>2019-02-12 18:42:37 -0300
commit8c67d29fd51c0381d8bce41d35d7726725924616 (patch)
treee90531012a6cae15b6857c70649bf921365ae467 /src
parentd357a16997a2e9dce0f56299c739b2b2584c4026 (diff)
downloadpostgresql-8c67d29fd51c0381d8bce41d35d7726725924616.tar.gz
postgresql-8c67d29fd51c0381d8bce41d35d7726725924616.zip
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
Diffstat (limited to 'src')
-rw-r--r--src/backend/replication/logical/reorderbuffer.c14
1 files changed, 9 insertions, 5 deletions
diff --git a/src/backend/replication/logical/reorderbuffer.c b/src/backend/replication/logical/reorderbuffer.c
index a49e226967c..2b486b5e9f3 100644
--- a/src/backend/replication/logical/reorderbuffer.c
+++ b/src/backend/replication/logical/reorderbuffer.c
@@ -1326,15 +1326,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;
}
}