From: | "Tristan Partin" <tristan(at)neon(dot)tech> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Two small bugs in guc.c |
Date: | 2023-12-27 18:26:42 |
Message-ID: | CXZBTBI4CC14.19ODDAQ7T9KMB@neon.tech |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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)
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2023-12-27 19:53:27 | Re: introduce dynamic shared memory registry |
Previous Message | Tristan Partin | 2023-12-27 18:20:22 | Re: Add support for __attribute__((returns_nonnull)) |