Re: PANIC in heap_delete during ALTER TABLE

Jeff Davis <pgsql@j-davis.com>

From: Jeff Davis <pgsql@j-davis.com>
To: Robins Tharakan <tharakan@gmail.com>, pgsql-bugs@postgresql.org
Date: 2022-09-07T21:53:17Z
Lists: pgsql-bugs

Attachments

On Mon, 2022-08-22 at 13:32 +0930, Robins Tharakan wrote:
> Hi,
> 
> During ALTER TABLE, heap_delete() can PANIC with the error
> "PANIC:  wrong buffer passed to visibilitymap_clear".

Thank you for the detailed report!

> Given below are backtraces on master, REL_15_STABLE and
> REL_13_STABLE.
> There was a similar discussion last year [1], although that was about
> heap_update() and was soon fixed [2]; thus reporting this as a
> separate
> thread.

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.

Repro on master:

---------------------------------------
GDB attached to session 2:
   break vacuumlazy.c:1243
   continue

Session 1:
   create table foo(i int) with (autovacuum_enabled=false);
   create index foo_idx on foo (i);
   insert into foo select generate_series(1,100);
   delete from foo where i = 49;

Session 2:
   vacuum foo; -- hits breakpoint

Session 3:
   begin;
   select i from foo where i = 50 for update;

Session 1:
   delete from foo where i = 50;

GDB:
   continue

Session 3:
   commmit;

---------------------------------------

I attached a hasty patch that seems to fix it. I'll need to look more
closely later, and I'll also need some review because there have been
multiple bugs in this area.

Regards,
	Jeff Davis

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.