Subject: Re: Logging replication state changes

From: SATYANARAYANA NARLAPURAM <[email-masked]>
Date: Sat, 8 Jan 2022 13:29:30 -0800

On Sat, Jan 8, 2022 at 3:26 AM Amit Kapila <[email-masked]> wrote:

> On Thu, Dec 30, 2021 at 4:18 AM SATYANARAYANA NARLAPURAM
> <[email-masked]> wrote:
> >
> > On Wed, Dec 29, 2021 at 2:04 PM Tom Lane <[email-masked]> wrote:
> >>
> >> SATYANARAYANA NARLAPURAM <[email-masked]> writes:
> >> > I noticed that below critical replication state changes are DEBUG1
> level
> >> > logged. Any concern about changing the below two messages log level
> to LOG?
> >>
> >> Why?  These seem like perfectly routine messages.
> >
> >
> > Consider a scenario where we have a primary and two sync standby (s1 and
> s2) where s1 is a preferred failover target and s2 is next with
> synchronous_standby_names = 'First 1 ('s1','s2')'.  In an event, s1
> streaming replication is broken and reestablished because of a planned or
> an unplanned event then s2 participates in the sync commits and makes sure
> the writes are not stalled on the primary. I would like to know the time
> window where s1 is not actively acknowledging the commits and the writes
> are dependent on s2. Also if the service layer decides to failover to s2
> instead of s1 because s1 is lagging I need evidence in the log to explain
> the behavior.
> >
>
> Isn't it better to get this information via pg_stat_replication view
> (via state and sync_priority) columns?
>

We need the historical information to analyze and root cause in addition to
the live debugging. It would be good to have better control over
replication messages.

> --
> With Regards,
> Amit Kapila.