]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Avoid improbable PANIC during heap_update, redux.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 30 Sep 2022 23:36:46 +0000 (19:36 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 30 Sep 2022 23:36:46 +0000 (19:36 -0400)
commit92941f26435ce3910bb9320fd92bda1e3dd4c6b5
tree0ed2a6731304c9ff368eab5d0420fbeced75199f
parenta3de685013e7f3c0bf624e037a5569c0d5f8f0c2
Avoid improbable PANIC during heap_update, redux.

Commit 34f581c39 intended to ensure that RelationGetBufferForTuple
would acquire a visibility-map page pin in case the otherBuffer's
all-visible bit had become set since we last had lock on that page.
But I missed a case: when we're extending the relation, VM concerns
were dealt with only in the relatively-less-likely case that we
fail to conditionally lock the otherBuffer.  I think I'd believed
that we couldn't need to worry about it if the conditional lock
succeeds, which is true for the target buffer; but the otherBuffer
was unlocked for awhile so its bit might be set anyway.  So we need
to do the GetVisibilityMapPins dance, and then also recheck the
page's free space, in both cases.

Per report from Jaime Casanova.  Back-patch to v12 as the previous
patch was (although there's still no evidence that the bug is
reachable pre-v14).

Discussion: https://postgr.es/m/E1lWLjP-00006Y-Ml@gemulon.postgresql.org
src/backend/access/heap/hio.c