Re: Clear logical slot's 'synced' flag on promotion of standby

On Thu, Sep 11, 2025 at 3:16 PM Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
>
> Hi,
>
>
> We already read the recovery signal files (standby.signal or
> recovery.signal) at the start of StartupXLOG() via InitWalRecovery(),
> which sets the StandbyModeRequested flag. Couldn’t we use this to
> distinguish whether the server is a primary undergoing crash recovery
> or a standby?
>

The objective is not to distinguish between a primary and a standby
undergoing crash recovery, but to differentiate between a primary
undergoing crash recovery and a promoted standby (now the new primary)
during the immediate next startup—specifically in cases where the
promotion failed late in the process, such as during ResetSyncedSlots.
StandbyModeRequested will be false in both the cases and thus cannot
be used.

> >
> >
> I attempted to
> > simulate a scenario where a regular standby ends up in
> > DB_IN_CRASH_RECOVERY after a crash, but I couldn't reproduce it. Do
> > you know of any situation where this could happen? The absence of
> > comments for these states makes it challenging to follow the flow.
> >
>
> The log message for "case DB_IN_CRASH_RECOVERY:" inside StartupXLOG
> should indicate that the server has entered crash recovery, no? And..
> If you still want the server to crash while in this state, you could
> add your own PANIC or FATAL error message inside the startupxlog.
>

I think my query was not correctly understood. The intent was to know
if we can ever hit 'DB_IN_CRASH_RECOVERY' on a regular standby. But, I
think the answer is 'No'. We can hit it on primary (before , during,
or after promotion after a crash).

thanks
Shveta