Re: PANIC in heap_delete during ALTER TABLE

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: PANIC in heap_delete during ALTER TABLE
Дата
Msg-id CAH2-Wzn2NUa9NOmtAqPVix0cNtcQtn6nu4rrCpETYAUQy0t2Dw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PANIC in heap_delete during ALTER TABLE  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-bugs
On Thu, Sep 15, 2022 at 3:25 PM Jeff Davis <pgsql@j-davis.com> wrote:
> heap_delete() lets go of its exclusive lock (but not pin) in a couple
> places (just like on master). But it looks like all the places that set
> PD_ALL_VISIBLE are doing so under a cleanup lock (unlike master), which
> means that it can't change for the duration of heap_delete().
>
> I'm hesitant to commit anything here if I can't repro the problem on
> 13. I must be missing something.

What about Hot Standby? There was never a rule that said that we had
to have a cleanup lock to set PD_ALL_VISIBLE during original execution
(or in recovery), even before Postgres 14. I believe that Postgres 14
was the first version to do it without a cleanup lock during original
execution. But it wasn't the first version to do it during recovery.

Based on a quick look just now: the heap_xlog_visible() REDO routine
is processed as an independent atomic action on replicas. It doesn't
require a cleanup lock for this, and never has. It may or may not be
preceded by a prune operation for the same page (in any case obviously
we won't keep the cleanup lock after the prune REDO routine runs).

-- 
Peter Geoghegan



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: PANIC in heap_delete during ALTER TABLE
Следующее
От: Souvik Chatterjee
Дата:
Сообщение: Re: BUG #17615: Getting error while inserting records in the table: invalid byte sequence for encoding "UTF8": 0xae