Logging replication state changes

Поиск
Список
Период
Сортировка
От SATYANARAYANA NARLAPURAM
Тема Logging replication state changes
Дата
Msg-id CAHg+QDd43_PaT=2=qypL4iHOPJb62xOnC69t3giUH5msmCK7Ug@mail.gmail.com
обсуждение исходный текст
Ответы Re: Logging replication state changes  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Strange path from pgarch_readyXlog()
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Logging replication state changes