Re: Logging replication state changes

On Sat, Jan 8, 2022 at 3:26 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:

> On Thu, Dec 30, 2021 at 4:18 AM SATYANARAYANA NARLAPURAM
> <satyanarlapuram(at)gmail(dot)com> wrote:
> >
> > On Wed, Dec 29, 2021 at 2:04 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >>
> >> SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com> 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.
>