aboutsummaryrefslogtreecommitdiff
path: root/contrib/postgres_fdw/postgres_fdw.c
diff options
context:
space:
mode:
authorMichael Paquier <michael@paquier.xyz>2022-10-13 09:31:57 +0900
committerMichael Paquier <michael@paquier.xyz>2022-10-13 09:31:57 +0900
commit56b662523fd49f75abe89d5bad54d377b2f36c24 (patch)
treeabd05f0acbf8831b1b88fa189a01ae2fcd922d9c /contrib/postgres_fdw/postgres_fdw.c
parent63585b1ebd0d5ee66ff8f801202656d40ff9bb63 (diff)
downloadpostgresql-56b662523fd49f75abe89d5bad54d377b2f36c24.tar.gz
postgresql-56b662523fd49f75abe89d5bad54d377b2f36c24.zip
Fix ordering issue with WAL operations in GIN fast insert path
Contrary to what is documented in src/backend/access/transam/README, ginHeapTupleFastInsert() had a few ordering issues with the way it does its WAL operations when inserting items in its fast path. First, when using a separate list, XLogBeginInsert() was being always called before START_CRIT_SECTION(), and in this case a second thing was wrong when merging lists, as an exclusive lock was taken on the tail page *before* calling XLogBeginInsert(). Finally, when inserting items into a tail page, the order of XLogBeginInsert() and START_CRIT_SECTION() was reversed. This commit addresses all these issues by moving the calls of XLogBeginInsert() after all the pages logged are locked and pinned, within a critical section. Author: Matthias van de Meent, Zhang Mingli Discussion: https://postgr.es/m/CAEze2WhL8uLMqynnnCu1LAPwxD5RKEo0nHV+eXGg_N6ELU88HQ@mail.gmail.com
Diffstat (limited to 'contrib/postgres_fdw/postgres_fdw.c')
0 files changed, 0 insertions, 0 deletions