On Sat, Jan 8, 2022 at 3:26 AM Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Thu, Dec 30, 2021 at 4:18 AM SATYANARAYANA NARLAPURAM
> <satyanarlapu...@gmail.com> wrote:
> >
> > On Wed, Dec 29, 2021 at 2:04 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
> >>
> >> SATYANARAYANA NARLAPURAM <satyanarlapu...@gmail.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.
>
