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
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 |