| From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Reduce log level of some logical decoding messages to DEBUG1 |
| Date: | 2026-03-25 03:28:23 |
| Message-ID: | CALj2ACXwe+iVoE50epmfGahYfoeBadgRr8ADvNHshWn0svv9hw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Tue, Mar 24, 2026 at 8:15 PM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>
> On Tue, Mar 24, 2026 at 12:44 AM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> > > > Alternatively, if we want to keep them at LOG by default, we could introduce
> > > > a GUC like trace_logical_decoding_messages, similar to
> > > > the old trace_recovery_messages, to control their verbosity independently
> > > > of log_min_messages.
>
> Just in case where many users still want to see those log messages at LOG level,
> I also created a second patch (0002) that introduces a new GUC,
> trace_logical_decoding_messages, to control logging of logical
> decoding debug messages (e.g., "logical decoding found consistent point").
-1 for another GUC. If needed, we could explore using
log_replication_commands, but I'm okay with your other suggestion on
using the new feature with log_min_messages. Perhaps, we could wait
for some time to hear from others.
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-03-25 03:29:52 | Re: Fixes inconsistent behavior in vacuum when it processes multiple relations |
| Previous Message | Andy Fan | 2026-03-25 03:27:10 | Re: raise ERROR between EndPrepare and PostPrepare_Locks causes ROLLBACK 2pc PAINC |