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

On Wed, 16 Jul 2025 at 09:09, Fujii Masao <masao.fujii@gmail.com> wrote:
>
> >
> > Included it for dblink and fdw
>
> Thanks! It's better to submit each change for dblink and postgres_fdw
> as separate patches, and first focus on the patch that sets the notice
> processor for replication connections.

Modified

> > > +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.
>
> Thanks for updating the patch!
>
> + /* Trim trailing newline for cleaner logs */
> + size_t len = strlen(message);
> +
> + if (len > 0 && message[len - 1] == '\n')
> + ereport(LOG,
> + errmsg("Received message from publisher: %.*s",
> + (int) (len - 1), message));
>
> Do we really need to trim the trailing newline? Are there actual
> WARNING/NOTICE/INFO messages that include an unnecessary newline?

If we don't trim the trailing newline, an extra blank line will appear
after the message is printed, like this:
2025-07-16 12:44:20.076 IST [534376] LOG:  logical replication table
synchronization worker for subscription "sub1", table "t2" has started
2025-07-16 12:44:20.294 IST [534374] LOG:  received message via
replication: WARNING:  could not remove directory
"pg_replslot/pg_16396_sync_16384_7527574647116269356.tmp"

2025-07-16 12:44:20.294 IST [534374] LOG:  logical replication table
synchronization worker for subscription "sub1", table "t1" has
finished

This occurs because a newline is appended to the message in
pqBuildErrorMessage3, which is called when the message is received in
pqGetErrorNotice3:
...
}
appendPQExpBufferChar(msg, '\n');
if (verbosity != PQERRORS_TERSE)
...

> "Received" should be lowercase, i.e., "received" since the primary log message
> should start with a lowercase letter, according to the Error Message
> Style Guide [1].

Modified

> The phrase "from publisher" could be misleading, since the sender might be
> a primary in physical replication, not necessarily a logical publisher.
> Maybe something like "received message via replication" would be clearer?
> I'd like to hear others' thoughts on a better wording.

Modified the message to "received message via replication." Will
update it further if we get any better wording.

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

Regards,
Vignesh