Re: PANIC in heap_delete during ALTER TABLE

On Thu, Sep 15, 2022 at 3:25 PM Jeff Davis <pgsql(at)j-davis(dot)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