Re: Logging replication state changes - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Logging replication state changes
Date
Msg-id CAA4eK1L1NVQhp9Y5mnUnfnnZ6ssePBY2Y8JZyLRe6Nu5rcVOBQ@mail.gmail.com
Whole thread Raw
In response to Re: Logging replication state changes  (SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>)
Responses Re: Logging replication state changes
List pgsql-hackers
On Thu, Dec 30, 2021 at 4:18 AM SATYANARAYANA NARLAPURAM
<satyanarlapuram@gmail.com> wrote:
>
> On Wed, Dec 29, 2021 at 2:04 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> SATYANARAYANA NARLAPURAM <satyanarlapuram@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
ands2 is next with synchronous_standby_names = 'First 1 ('s1','s2')'.  In an event, s1 streaming replication is broken
andreestablished because of a planned or an unplanned event then s2 participates in the sync commits and makes sure the
writesare not stalled on the primary. I would like to know the time window where s1 is not actively acknowledging the
commitsand the writes are dependent on s2. Also if the service layer decides to failover to s2 instead of s1 because s1
islagging 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?

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Non-superuser subscription owners
Next
From: Jeff Davis
Date:
Subject: Re: Non-superuser subscription owners