From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Robins Tharakan <tharakan(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: PANIC in heap_delete during ALTER TABLE |
Date: | 2022-09-07 22:44:41 |
Message-ID: | CAH2-Wz=s-ZJJ++wnnKx70iBSCMQ_kiRHD+K3NUX3P3qQcRKAbg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, Sep 7, 2022 at 2:53 PM Jeff Davis <pgsql(at)j-davis(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ming | 2022-09-08 02:02:51 | Postgres offset and limit bug |
Previous Message | Jeff Davis | 2022-09-07 21:53:17 | Re: PANIC in heap_delete during ALTER TABLE |