Two small bugs in guc.c
От | Tom Lane |
---|---|
Тема | Two small bugs in guc.c |
Дата | |
Msg-id | 2089235.1703617353@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Two small bugs in guc.c
("Tristan Partin" <tristan@neon.tech>)
|
Список | 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) 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. regards, tom lane [1] https://www.postgresql.org/message-id/flat/CAK30z9T9gaF_isNquccZxi7agXCSjPjMsFXiifmkfu4VpZguxw%40mail.gmail.com diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c index 959a1c76bf..4126b90ad7 100644 --- a/src/backend/utils/misc/guc.c +++ b/src/backend/utils/misc/guc.c @@ -3412,9 +3412,12 @@ set_config_with_handle(const char *name, config_handle *handle, * Other changes might need to affect other workers, so forbid them. */ if (IsInParallelMode() && changeVal && action != GUC_ACTION_SAVE) + { ereport(elevel, (errcode(ERRCODE_INVALID_TRANSACTION_STATE), errmsg("cannot set parameters during a parallel operation"))); + return -1; + } /* if handle is specified, no need to look up option */ if (!handle) @@ -3513,7 +3516,9 @@ set_config_with_handle(const char *name, config_handle *handle, * postmaster (whence it will propagate to * subsequently-started backends), but ignore it in existing * backends. This is a tad klugy, but necessary because we - * don't re-read the config file during backend start. + * don't re-read the config file during backend start. Handle + * this by clearing changeVal but continuing, since we do want + * to report incorrect values. * * In EXEC_BACKEND builds, this works differently: we load all * non-default settings from the CONFIG_EXEC_PARAMS file @@ -3526,7 +3531,7 @@ set_config_with_handle(const char *name, config_handle *handle, * applies. */ if (IsUnderPostmaster && !is_reload) - return -1; + changeVal = false; } else if (context != PGC_POSTMASTER && context != PGC_BACKEND &&
В списке pgsql-hackers по дате отправления: