Re: Up to 50x degradation in dblink performance when receiving notice traffic 19 vs 18 - Mailing list pgsql-hackers

From vignesh C
Subject Re: Up to 50x degradation in dblink performance when receiving notice traffic 19 vs 18
Date
Msg-id CALDaNm2YtVcq+__0-TdOgg7_YHoQKcc=yjD7zPtMgti-hdT3cw@mail.gmail.com
Whole thread
In response to Re: Up to 50x degradation in dblink performance when receiving notice traffic 19 vs 18  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On Fri, 25 Sept 2026 at 10:27, Fujii Masao <masao.fujii@gmail.com> wrote:
>
> On Fri, Sep 25, 2026 at 1:39 PM vignesh C <vignesh21@gmail.com> wrote:
> > Thanks for verifying, here is a v2 version
>
> Thanks for the patch!
> +1 to calling errhidestmt(true) and errhidecontext(true).
>
> + /*
> + * Don't log the local statement or context.  This runs once for every
> + * message the remote server sends, and LOG passes the default
> + * log_min_error_statement, so each message would otherwise repeat the
> + * whole text of whatever local query is running.  The local context only
> + * says where libpq happened to be reading input, not what caused the
> + * message.
> + */
>
> This comment sounds a bit redundant and indirect to me. How about a simpler
> one like this?
>
>     Omit the local statement and context from each remote message.
>     They can help identify the caller, but repeating them for every
>     message could greatly increase log volume.

Thanks, this looks enough. Here is an updated v3 version patch for the same.

Regards,
Vignesh

Attachment

pgsql-hackers by date:

Previous
From: Manu
Date:
Subject: Re: REPACK (CONCURRENTLY) can silently lose updates when the toast table is rewritten
Next
From: solai v
Date:
Subject: Re: Add a permission check to pg_stat_get_backend_subxact()