summaryrefslogtreecommitdiff
path: root/src/test/kerberos
diff options
context:
space:
mode:
authorNoah Misch <noah@leadboat.com>2021-10-23 18:36:38 -0700
committerNoah Misch <noah@leadboat.com>2021-10-23 18:36:38 -0700
commit3cd9c3b921977272e6650a5efbeade4203c4bca2 (patch)
treedded19edcddd83c542603cbb8eb14ce24b7ca762 /src/test/kerberos
parentfdd965d074d46765c295223b119ca437dbcac973 (diff)
downloadpostgresql-3cd9c3b921977272e6650a5efbeade4203c4bca2.tar.gz
Fix CREATE INDEX CONCURRENTLY for the newest prepared transactions.
The purpose of commit 8a54e12a38d1545d249f1402f66c8cde2837d97c was to fix this, and it sufficed when the PREPARE TRANSACTION completed before the CIC looked for lock conflicts. Otherwise, things still broke. As before, in a cluster having used CIC while having enabled prepared transactions, queries that use the resulting index can silently fail to find rows. It may be necessary to reindex to recover from past occurrences; REINDEX CONCURRENTLY suffices. Fix this for future index builds by making CIC wait for arbitrarily-recent prepared transactions and for ordinary transactions that may yet PREPARE TRANSACTION. As part of that, have PREPARE TRANSACTION transfer locks to its dummy PGPROC before it calls ProcArrayClearTransaction(). Back-patch to 9.6 (all supported versions). Andrey Borodin, reviewed (in earlier versions) by Andres Freund. Discussion: https://postgr.es/m/01824242-AA92-4FE9-9BA7-AEBAFFEA3D0C@yandex-team.ru
Diffstat (limited to 'src/test/kerberos')
0 files changed, 0 insertions, 0 deletions