Re: PANIC in heap_delete during ALTER TABLE
От | Jeff Davis |
---|---|
Тема | Re: PANIC in heap_delete during ALTER TABLE |
Дата | |
Msg-id | c0c149af17b358883e95a49984a30360b65f8118.camel@j-davis.com обсуждение исходный текст |
Ответ на | PANIC in heap_delete during ALTER TABLE (Robins Tharakan <tharakan@gmail.com>) |
Ответы |
Re: PANIC in heap_delete during ALTER TABLE
Re: PANIC in heap_delete during ALTER TABLE |
Список | pgsql-bugs |
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
Вложения
В списке pgsql-bugs по дате отправления: