Horton

Re: PANIC in heap_delete during ALTER TABLE

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Robins Tharakan <tharakan@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Date: 2022-09-07T22:44:41Z
Lists: pgsql-bugs 
On Wed, Sep 7, 2022 at 2:53 PM Jeff Davis <pgsql@j-davis.com> wrote:
> Yes, it looks like it's essentially the same issue.
>
> heap_delete() does recheck after locking the buffer correctly at the
> top, but there are other paths below which unlock/relock the buffer
> without checking to see if the VM pin should be acquired.

This certainly vindicates Tom's decision to backpatch his fix for the
heap_update() issue. Clearly this new variant bug can't have anything to do
with the 14-era behavioral change to lazy_vacuum_heap_page() from
commit 8523492d4e. That behavioral change was clearly a factor in the
heap_update() issue, but can't be relevant here. Since the repro we have
shows that 13 is also affected.

I wonder why it took this long to hear anything about it, though.
Maybe it just worked out that way because the earlier (or was it
later?) heap_update() issue created a public record that somebody like Robins
could find.


--
Peter Geoghegan

Commits

  1. Fix race condition where heap_delete() fails to pin VM page.

  2. Avoid improbable PANIC during heap_update.

  3. Remove tupgone special case from vacuumlazy.c.