Re: Excessive LOG messages from replication slot sync worker - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Excessive LOG messages from replication slot sync worker
Date
Msg-id CAA4eK1Lzm6uJzmuSFLzsL=LkJbTMmY-yFsv5thDdirZ=VD6iYw@mail.gmail.com
Whole thread Raw
In response to Re: Excessive LOG messages from replication slot sync worker  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On Thu, Aug 14, 2025 at 9:43 AM Fujii Masao <masao.fujii@gmail.com> wrote:
>
> On Wed, Aug 13, 2025 at 1:00 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Tue, Aug 12, 2025 at 4:28 PM Fujii Masao <masao.fujii@gmail.com> wrote:
> > >
> > > I'm not sure these messages are useful for end users, and LOG might not be
> > > the right level. They seem more like debug information, so should we consider
> > > changing them to DEBUG, even with the proposed patch applied?
> > >
> >
> > Yeah, we can do that for slotsync path but it should be okay to keep
> > at LOG level for logical replication/decoding path as there it
> > shouldn't hit as often as in slotsync path.
>
> It looks like those two LOG messages are also generated by
> pg_logical_slot_get_binary_changes(). When this function is
> called every few seconds to capture changes in real time,
> it can produce a large number of these messages.
>

I am not sure how plugin developers or users are using these
functions, but for built-in logical replication, these messages should
appear at the start of the walsender once. This area is relatively
complex so it becomes easier for us to understand the bug reports with
the help of these messages. TBH, I don't know if they are really
helpful for users so I see the merits of your point to change the
level of these LOGs. However, as a selfish developer who works on
various bugs in this area I found these and other logical decoding
messages quite useful to analyze the bug reports. I haven't checked
all but there is another message as follows which would fall in same
category:
elog(LOG, "%X/%08X has been already streamed, forwarding to %X/%08X",

BTW, I have not seen user reports where they complain about these
LOGs. Now, it is possible that users may not have noticed or maybe I
missed to spot such reports.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Fabrice Chapuis
Date:
Subject: Re: Issue with logical replication slot during switchover
Next
From: Julien Rouhaud
Date:
Subject: Re: pg_stat_statements: Add `calls_aborted` counter for tracking query cancellations