From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jaime Casanova <jcasanov@systemguards.com.ec>
Cc: pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Avoid improbable PANIC during heap_update.
Date: Fri, 30 Sep 2022 17:28:51 -0400
Message-ID: <692791.1664573331@sss.pgh.pa.us> (raw)
In-Reply-To: <YzdVJnQocQ6RHKxk@ahch-to>
References: <E1lWLjP-00006Y-Ml@gemulon.postgresql.org>
<YzVPfCKNrmi0aLEh@ahch-to>
<YzdVJnQocQ6RHKxk@ahch-to>
Jaime Casanova <jcasanov@systemguards.com.ec> writes:
> Just to confirm I saw this on RC1
Ugh ... I think I see the problem. There's still one path through
RelationGetBufferForTuple that fails to guarantee that it's acquired
a vmbuffer pin if the all-visible flag becomes set in the otherBuffer.
Namely, if we're forced to extend the relation, then we deal with
vm pins when ConditionalLockBuffer(otherBuffer) fails ... but not
when it succeeds. I think the fix is just to move the last
GetVisibilityMapPins call out of the "if
(unlikely(!ConditionalLockBuffer(otherBuffer)))" stanza.
It'd still be good to have a test case for this ...
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: tgl@sss.pgh.pa.us, jcasanov@systemguards.com.ec, pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Avoid improbable PANIC during heap_update.
In-Reply-To: <692791.1664573331@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox