Re: Two small bugs in guc.c
От | Tristan Partin |
---|---|
Тема | Re: Two small bugs in guc.c |
Дата | |
Msg-id | CXZBTBI4CC14.19ODDAQ7T9KMB@neon.tech обсуждение исходный текст |
Ответ на | Two small bugs in guc.c (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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)
В списке pgsql-hackers по дате отправления: