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.
In-reply-to: <YzdVJnQocQ6RHKxk@ahch-to>
References: <E1lWLjP-00006Y-Ml@gemulon.postgresql.org>
 <YzVPfCKNrmi0aLEh@ahch-to> <YzdVJnQocQ6RHKxk@ahch-to>
Comments: In-reply-to Jaime Casanova <jcasanov@systemguards.com.ec>
	message dated "Fri, 30 Sep 2022 15:44:22 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <692790.1664573331.1@sss.pgh.pa.us>
Date: Fri, 30 Sep 2022 17:28:51 -0400
Message-ID: <692791.1664573331@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/692791.1664573331%40sss.pgh.pa.us>
Precedence: bulk

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