Re: Log prefix missing for subscriber log messages received from publisher
От | Fujii Masao |
---|---|
Тема | Re: Log prefix missing for subscriber log messages received from publisher |
Дата | |
Msg-id | 641429f3-90a1-4e8d-bc9c-cdad445c81eb@oss.nttdata.com обсуждение исходный текст |
Ответ на | Log prefix missing for subscriber log messages received from publisher (vignesh C <vignesh21@gmail.com>) |
Ответы |
Re: Log prefix missing for subscriber log messages received from publisher
|
Список | pgsql-hackers |
On 2025/04/15 13:37, vignesh C wrote: > Hi, > > Currently, when a warning is emitted by the publisher, the > corresponding log message does not include the log prefix. This makes > it harder to correlate such messages with other log entries. For > example, in a simulated error scenario where directory removal fails, > the notice message lacks the standard log prefix, as shown below: > 2025-03-18 16:44:36.071 IST [196901] LOG: logical replication table > synchronization worker for subscription "sub1", table "t1" has > finished > WARNING: could not remove directory > "pg_replslot/pg_16398_sync_16387_7483106341004194035.tmp" > > In this case, the WARNING line does not include the usual timestamp > information, making it harder to trace. > > To address this, we can have a custom notice processor for WAL > receiver connections—similar to what's done in the attached patch. I like this idea. If this issue also exists other features like dblink or postgres_fdw connecting to remote PostgreSQL servers, it might be worth applying a similar improvement there as well. +notice_processor(void *arg, const char *message) +{ + elog(LOG, "%s", message); Should ereport() be used here instead? Also, would it be better to add some context before %s, for example, something like "received message from the primary:"? Without that, users might mistakenly think the message originated from the local server. Regards, -- Fujii Masao NTT DATA Japan Corporation
В списке pgsql-hackers по дате отправления: