aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/transam/xlogutils.c
diff options
context:
space:
mode:
authorAndres Freund <andres@anarazel.de>2023-04-06 11:11:13 -0700
committerAndres Freund <andres@anarazel.de>2023-04-06 11:11:13 -0700
commit18103b7c5f1aed4ca22f75229346eddb6e20d725 (patch)
tree5a0b4f39790de0f266fbce3c5d7cc08c3b14b758 /src/backend/access/transam/xlogutils.c
parentbba9003b627f4742212bd060ae65fe5c9c3592f3 (diff)
downloadpostgresql-18103b7c5f1aed4ca22f75229346eddb6e20d725.tar.gz
postgresql-18103b7c5f1aed4ca22f75229346eddb6e20d725.zip
hio: Don't pin the VM while holding buffer lock while extending
Starting with commit 7db0cd2145f, RelationGetBufferForTuple() did a visibilitymap_pin() while holding an exclusive buffer content lock on a newly extended page, when using COPY FREEZE. We elsewhere try hard to avoid to doing IO while holding a content lock. And until 14f98e0af99, that happened while holding the relation extension lock. Practically, this isn't a huge issue, because COPY FREEZE is restricted to relations created or truncated in the current session, so it's unlikely there's a lot of contention. We can't avoid doing IO while holding the content lock by pinning the VM earlier, because we don't know which page it will be on. While we could just ignore the issue in this case, a future commit will add bulk relation extension, which needs to enter pages into the FSM while also trying to hold onto a buffer lock. To address this issue, use visibilitymap_pin_ok() to see if the relevant buffer is already pinned. If not, release the buffer, pin the VM buffer, and acquire the lock again. This opens up a small window for other backends to insert data onto the page - as the page is not entered into the freespacemap, other backends won't see it normally, but a concurrent vacuum could enter the page, if it started just after the relation is extended. In case the page is used by another backend, retry. This is very similar to how locking "otherBuffer" is already dealt with. Reviewed-by: Tomas Vondra <tomas.vondra@enterprisedb.com> Discussion: http://postgr.es/m/20230325025740.wzvchp2kromw4zqz@awork3.anarazel.de
Diffstat (limited to 'src/backend/access/transam/xlogutils.c')
0 files changed, 0 insertions, 0 deletions