aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistproc.c
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
commitc2e0954be36390f06e1a8821921648bc258c38bf (patch)
treea8e63a6591b5feeeda77749d2170211c66a18691 /src/backend/access/gist/gistproc.c
parenta4c6a73aa438d6c44fbe1e5e0c8878051e8c2b54 (diff)
downloadpostgresql-c2e0954be36390f06e1a8821921648bc258c38bf.tar.gz
postgresql-c2e0954be36390f06e1a8821921648bc258c38bf.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/backend/access/gist/gistproc.c')
0 files changed, 0 insertions, 0 deletions