Two small bugs in guc.c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Two small bugs in guc.c
Date: 2023-12-26 19:02:33
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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)
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.

regards, tom lane


Attachment Content-Type Size
v1-fix-set_config_option-logic-bugs.patch text/x-diff 1.5 KB


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-12-26 19:19:04 Re: Statistics Import and Export
Previous Message Bruce Momjian 2023-12-26 18:55:20 Re: Moving forward with TDE