On Thu, Apr 2, 2026 at 8:45 PM Fujii Masao <[email protected]> wrote: > > If something goes wrong, enabling the messages for the future > > won't tell you what went wrong in the past. I am wondering whether a > > better approach might be to set the LOG level based on context -- that > > is, if it's actually logical decoding, log this at LOG, but if it's > > just someone peeking at a slot or similar, reduce the log level to > > DEBUG1 or, really, probably more like DEBUG3. > > You are suggesting something like that logical walsender and > pg_logical_slot_get_changes() should log at LOG, while the slotsync worker > should use DEBUG? Sorry, I may be misunderstanding, since the slotsync worker > can also use logical decoding mechanism internally. Could you clarify what you > have in mind by "peeking at a slot or similar"?
No, what I mean is that if someone runs an SQL function from the foreground, they probably don't want that to result in a LOG message, but if background activity results in such a message, the LOG message is probably a good idea. The reasons are: 1. Somebody might run many foreground queries that rely on the logical decoding infrastructure, so logging something every time such a query is executed could produce a lot of log spam. But there shouldn't be so much background logical decoding for this to be an issue. 2. If logical replication is not working, that may be a major issue for the DBA. A problem running pg_logical_slot_get_changes() is likely not as critical (and if it is, they can always lower client_min_messages or log_min_messages for that session only). -- Robert Haas EDB: http://www.enterprisedb.com
