On Sat, Jan 8, 2022, at 6:29 PM, SATYANARAYANA NARLAPURAM wrote:
> 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.
I think the answer to this demand is not to change the message
On Sat, Jan 8, 2022 at 3:26 AM Amit Kapila wrote:
> On Thu, Dec 30, 2021 at 4:18 AM SATYANARAYANA NARLAPURAM
> wrote:
> >
> > On Wed, Dec 29, 2021 at 2:04 PM Tom Lane wrote:
> >>
> >> SATYANARAYANA NARLAPURAM writes:
> >> > I noticed that below critical replication state changes are DEBUG1
> l
On Thu, Dec 30, 2021 at 4:18 AM SATYANARAYANA NARLAPURAM
wrote:
>
> On Wed, Dec 29, 2021 at 2:04 PM Tom Lane wrote:
>>
>> SATYANARAYANA NARLAPURAM writes:
>> > I noticed that below critical replication state changes are DEBUG1 level
>> > logged. Any concern about changing the below two messages
On Wed, Dec 29, 2021 at 2:04 PM Tom Lane wrote:
> SATYANARAYANA NARLAPURAM 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.
SATYANARAYANA NARLAPURAM 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.
regards, tom lane
Hi hackers,
I noticed that below critical replication state changes are DEBUG1 level
logged. Any concern about changing the below two messages log level to LOG?
If this is too verbose, we can introduce a new GUC,
log_replication_state_changes that logs the replication state changes when
enabled ir
