Re: pgsql: Avoid improbable PANIC during heap_update. - Mailing list pgsql-committers

From Peter Geoghegan
Subject Re: pgsql: Avoid improbable PANIC during heap_update.
Date
Msg-id CAH2-WzmpfcbFxb=CNC4JiCzLLCGrWyWSV2kxaXVew9owKk4nrA@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Avoid improbable PANIC during heap_update.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgsql: Avoid improbable PANIC during heap_update.
List pgsql-committers
On Fri, Sep 30, 2022 at 4:52 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:> >
I would be more confident here were it not for the recent
> > heap_delete() issue reported by one of my AWS colleagues (and fixed by
> > another, Jeff Davis). See commit 163b0993 if you missed it before now.
>
> Hmm, okay, though that's really a distinct bug of the same ilk.
> You're right that I'd not paid close attention to that thread after
> Jeff diagnosed the problem.

I just meant that I don't feel particularly confident about what might
be possible or likely in Postgres 14 with this new issue in
heap_update() on point releases without today's bugfix. My theory
about lazy_scan_noprune() might be correct, but take it with a grain
of salt.

> It does seem like Robins' report
> shows that there's some way that v13 will set the AV bit without
> a cleanup lock ... does that constitute a bug in itself?

We never got to the bottom of that part, strangely enough. I can ask again.

In any case we cannot really treat the information that we have about
that as a bug report -- not as things stand. Why should the question
of whether or not we ever set a page PD_ALL_VISIBLE without a cleanup
lock on v13 be a mystery at all? Why wouldn't a simple grep get to the
bottom of it? I have to imagine that the true explanation is very
simple and boring.

-- 
Peter Geoghegan



pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Avoid improbable PANIC during heap_update.
Next
From: Peter Geoghegan
Date:
Subject: Re: pgsql: Avoid improbable PANIC during heap_update.