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 по дате отправления: