pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tristan Partin <tristan@neon.tech>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Subject: Re: Two small bugs in guc.c
Date: Wed, 27 Dec 2023 12:26:42 -0600
Message-ID: <CXZBTBI4CC14.19ODDAQ7T9KMB@neon.tech> (raw)
In-Reply-To: <2089235.1703617353@sss.pgh.pa.us>
References: <2089235.1703617353@sss.pgh.pa.us>

On Tue Dec 26, 2023 at 1:02 PM CST, Tom Lane wrote:
> I investigated the report at [1] about pg_file_settings not reporting
> invalid values of "log_connections".  It turns out it's broken for
> PGC_BACKEND and PGC_SU_BACKEND parameters, but not other ones.
> The cause is a bit of premature optimization in this logic:
>
>                  * If a PGC_BACKEND or PGC_SU_BACKEND parameter is changed in
>                  * the config file, we want to accept the new value in the
>                  * postmaster (whence it will propagate to
>                  * subsequently-started backends), but ignore it in existing
>                  * backends. ...
>
> Upon detecting that case, set_config_option just returns -1 immediately
> without bothering to validate the value.  It should check for invalid
> input before returning -1, which we can mechanize with a one-line fix:
>
> -                    return -1;
> +                    changeVal = false;
>
> While studying this, I also noted that the bit to prevent changes in
> parallel workers seems seriously broken:
>
>     if (IsInParallelMode() && changeVal && action != GUC_ACTION_SAVE)
>         ereport(elevel,
>                 (errcode(ERRCODE_INVALID_TRANSACTION_STATE),
>                  errmsg("cannot set parameters during a parallel operation")));
>
> This is evidently assuming that ereport() won't return, which seems
> like a very dubious assumption given the various values that elevel
> can have.  Maybe it's accidentally true -- I don't recall any
> reports of trouble here -- but it sure looks fragile.
>
> Hence, proposed patch attached.

Looks good to me.

--
Tristan Partin
Neon (https://neon.tech)





view thread (2+ messages)

Message-ID: <CXZBTBI4CC14.19ODDAQ7T9KMB@neon.tech>
Permalink:  ../CXZBTBI4CC14.19ODDAQ7T9KMB@neon.tech/
Also on:    postgresql.org/message-id/CXZBTBI4CC14.19ODDAQ7T9KMB@neon.tech

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tristan@neon.tech, tgl@sss.pgh.pa.us, pgsql-hackers@lists.postgresql.org
  Subject: Re: Two small bugs in guc.c
  In-Reply-To: <CXZBTBI4CC14.19ODDAQ7T9KMB@neon.tech>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox