Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display
От | Michael Paquier |
---|---|
Тема | Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display |
Дата | |
Msg-id | YZMh71bIIy6lOGM1@paquier.xyz обсуждение исходный текст |
Ответ на | Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display ("Bossart, Nathan" <bossartn@amazon.com>) |
Ответы |
Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display
|
Список | pgsql-hackers |
On Mon, Nov 15, 2021 at 10:36:09PM +0000, Bossart, Nathan wrote: > + ereport(DEBUG1, > + (errmsg_internal("executing archive command \"%s\" for archving %s", > + xlogarchcmd, xlog))); > > I wonder if it's necessary to include the "for archiving" part in this > one. Typically, the xlogarchcmd will include it somewhere. Don't see any need to add that either (s/archving/archiving/, btw). @@ -1000,6 +1004,10 @@ XLogWalRcvFlush(bool dying, TimeLineID tli) + ereport(DEBUG1, + (errmsg_internal("streaming %X/%X", + LSN_FORMAT_ARGS(LogstreamResult.Write)))); Having the same wording for the WAL receiver and the WAL sender could be confusing when it comes to a cascading standby node, particularly if log_line_prefix does not include the process PID. + ereport(DEBUG1, + (errmsg_internal("streaming %X/%X", + LSN_FORMAT_ARGS(sentPtr)))); Anyway, those two ones are going to make the logs much more noisy, no? The same could be said about XLogFileRead(), joining the point of Nathan's upthread. So I cannot get excited by this change. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: