From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: 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:56:11 -0400
Message-ID: <741997.1664574971@sss.pgh.pa.us> (raw)
In-Reply-To: <CAH2-Wz=Apna8uQAxdBUTTZX10baV-MsT9FyV6o-ifZD+knwVEQ@mail.gmail.com>
References: <E1lWLjP-00006Y-Ml@gemulon.postgresql.org>
<YzVPfCKNrmi0aLEh@ahch-to>
<YzdVJnQocQ6RHKxk@ahch-to>
<692791.1664573331@sss.pgh.pa.us>
<CAH2-Wz=Apna8uQAxdBUTTZX10baV-MsT9FyV6o-ifZD+knwVEQ@mail.gmail.com>
Peter Geoghegan <pg@bowt.ie> writes:
> On Fri, Sep 30, 2022 at 2:28 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
> FWIW it seems possible that the Postgres 15 vacuumlazy.c work that
> added lazy_scan_noprune() made this scenario more likely in practice
> -- even compared to Postgres 14.
Could be, because we haven't seen field reports of this in v14 yet.
And there's still no hard evidence of a bug pre-14. Nonetheless,
I'm inclined to backpatch to v12 as 34f581c39 was.
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, pg@bowt.ie, jcasanov@systemguards.com.ec, pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Avoid improbable PANIC during heap_update.
In-Reply-To: <741997.1664574971@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