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

On Mon, 14 Jul 2025 at 21:36, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
>
>
>
> 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.

Included it for dblink and fdw

> +notice_processor(void *arg, const char *message)
> +{
> + elog(LOG, "%s", message);
>
> Should ereport() be used here instead?

Yes, that is better. Modified it to ereport

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

Yes, that makes sense. Updated accordingly.

For dblink and postgres_fdw, create the dblink and postgres_fdw setup
and create the below object to raise a notice:
CREATE OR REPLACE FUNCTION emit_notice(msg text) RETURNS int AS $$
BEGIN
RAISE NOTICE '%', msg;
RETURN 1;
END;
$$ LANGUAGE plpgsql;

CREATE VIEW my_notice_view AS SELECT 1 AS value;

CREATE OR REPLACE RULE "_RETURN" AS
ON SELECT TO my_notice_view
DO INSTEAD
SELECT 1 AS value
FROM (SELECT emit_notice('NOTICE from _RETURN rule') AS dummy) s;

-- Scenario to see the notice raised by remote server using dblink
SELECT * FROM dblink('dbname=remotedb user=remoteuser', 'SELECT *
FROM my_notice_view') AS t(value int);

-- Scenario to see the notice raised by remote server using postgres_fdw
IMPORT FOREIGN SCHEMA public LIMIT TO (my_notice_view) FROM SERVER
foreign_server INTO public;

The attached v2 version patch has the changes for the same.

Regards,
Vignesh