Logging replication state changes - Mailing list pgsql-hackers

From SATYANARAYANA NARLAPURAM
Subject Logging replication state changes
Date
Msg-id CAHg+QDd43_PaT=2=qypL4iHOPJb62xOnC69t3giUH5msmCK7Ug@mail.gmail.com
Whole thread Raw
Responses Re: Logging replication state changes
List pgsql-hackers
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 irrespective of the log level. 

1/ 

/*
 * If we're in catchup state, move to streaming.  This is an
 * important state change for users to know about, since before
 * this point data loss might occur if the primary dies and we
 * need to failover to the standby. The state change is also
 * important for synchronous replication, since commits that
 * started to wait at that point might wait for some time.
 */
if (MyWalSnd->state == WALSNDSTATE_CATCHUP)
{
ereport(DEBUG1,
(errmsg_internal("\"%s\" has now caught up with upstream server",
application_name)));
WalSndSetState(WALSNDSTATE_STREAMING);
}

2/

ereport(DEBUG1,
(errmsg_internal("standby \"%s\" now has synchronous standby priority %u",
application_name, priority)));


Thanks,
Satya

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Strange path from pgarch_readyXlog()
Next
From: Tom Lane
Date:
Subject: Re: Logging replication state changes