Re: Log prefix missing for subscriber log messages received from publisher

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Log prefix missing for subscriber log messages received from publisher
Date: 2025-07-14 16:06:11
Message-ID: 641429f3-90a1-4e8d-bc9c-cdad445c81eb@oss.nttdata.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2025-07-14 16:24:14 Re: Horribly slow pg_upgrade performance with many Large Objects
Previous Message Fabrice Chapuis 2025-07-14 15:40:24 Re: failover logical replication slots