Re: persist logical slots to disk during shutdown checkpoint

On Mon, Aug 21, 2023 at 6:36 PM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
>
> On Sun, Aug 20, 2023 at 8:40 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > The other possibility is that we introduce yet another dirty flag for
> > slots, say dirty_for_shutdown_checkpoint which will be set when we
> > update confirmed_flush LSN. The flag will be cleared each time we
> > persist the slot but we won't persist if only this flag is set. We can
> > then use it during the shutdown checkpoint to decide whether to
> > persist the slot.
>
> There are already two booleans controlling dirty-ness of slot, dirty
> and just_dirty. Adding third will created more confusion.
>
> Another idea is to record the confirm_flush_lsn at the time of
> persisting the slot. We can use it in two different ways 1. to mark a
> slot dirty and persist if the last confirm_flush_lsn when slot was
> persisted was too far from the current confirm_flush_lsn of the slot.
> 2. at shutdown checkpoint, persist all the slots which have these two
> confirm_flush_lsns different.
>

I think using it in the second (2) way sounds advantageous as compared
to storing another dirty flag because this requires us to update
last_persisted_confirm_flush_lsn only while writing the slot info.
OTOH, having a flag dirty_for_shutdown_checkpoint will require us to
update it each time we update confirm_flush_lsn under spinlock at
multiple places. But, I don't see the need of doing what you proposed
in (1) as the use case for it is very minor, basically this may
sometimes help us to avoid decoding after crash recovery.

--
With Regards,
Amit Kapila.