From: | SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Logging replication state changes |
Date: | 2021-12-29 21:23:49 |
Message-ID: | CAHg+QDd43_PaT=2=qypL4iHOPJb62xOnC69t3giUH5msmCK7Ug@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-12-29 22:04:31 | Re: Logging replication state changes |
Previous Message | Tom Lane | 2021-12-29 21:04:12 | Re: Strange path from pgarch_readyXlog() |