Re: Log prefix missing for subscriber log messages received from publisher - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Log prefix missing for subscriber log messages received from publisher
Date
Msg-id c23bd40f-1495-4612-8210-72ebb18156bf@oss.nttdata.com
Whole thread Raw
In response to Re: Log prefix missing for subscriber log messages received from publisher  (vignesh C <vignesh21@gmail.com>)
Responses Re: Log prefix missing for subscriber log messages received from publisher
List pgsql-hackers

On 2025/07/16 19:45, vignesh C wrote:
> 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)
> ...

You're right, the message text passed to the notice processor includes
a trailing newline. I confirmed this is documented in the PQsetNoticeProcessor
docs [1], so I agree it's reasonable to trim the newline for cleaner log output.


Regarding the current implementation:
+       /* Trim trailing newline for cleaner logs */
+       size_t          len = strlen(message);
+
+       if (len > 0 && message[len - 1] == '\n')
+               ereport(LOG,
+                               errmsg("received message via replication: %.*s",
+                                          (int) (len - 1), message));
+       else
+               ereport(LOG,
+                               errmsg("received message via replication: %s", message));

To avoid repeating ereport(), how about refactoring it like this?
I think it's simpler and easier to read:

---------------------------------------
/*
  * Custom notice processor for replication connection.
  */
static void
notice_processor(void *arg, const char *message)
{
    int            len;

    /*
     * Trim the trailing newline from the message text passed to the notice
     * processor, as it always includes one, to produce cleaner log output.
     */
    len = strlen(message);
    if (len > 0 && message[len - 1] == '\n')
        len--;

    ereport(LOG,
            errmsg("received message via replication: %.*s",
                   len, message));
}
---------------------------------------


Also, I suggest adding the prototype for notice_processor() in libpqwalreceiver.c:

---------------------------------------
/* Prototypes for private functions */
static void notice_processor(void *arg, const char *message);
static char *stringlist_to_identifierstr(PGconn *conn, List *strings);
---------------------------------------


Currently, notice_processor() is placed just before libpqrcv_connect(),
but I think it would be better to move it before stringlist_to_identifierstr(),
since the libpqwalreceiver.c seems to follow a structure where private
functions come after the libpqrcv_* functions.


+       PQsetNoticeProcessor(conn->streamConn, notice_processor, NULL);

It might be helpful to add a comment explaining the purpose, such as:

     Set a custom notice processor so that notice, warning, and similar messages
     received via the replication connection are logged in our preferred style,
     instead of just being printed to stderr.

Thought?

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

+1

Regards,

[1] https://www.postgresql.org/docs/devel/libpq-notice-processing.html

-- 
Fujii Masao
NTT DATA Japan Corporation




pgsql-hackers by date:

Previous
From: Xuneng Zhou
Date:
Subject: Re: Add progressive backoff to XactLockTableWait functions
Next
From: Andres Freund
Date:
Subject: Re: Explicitly enable meson features in CI