Re: A assert failure when initdb with track_commit_timestamp=on
От | Tom Lane |
---|---|
Тема | Re: A assert failure when initdb with track_commit_timestamp=on |
Дата | |
Msg-id | 249358.1751643017@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: A assert failure when initdb with track_commit_timestamp=on (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Ответы |
Re: A assert failure when initdb with track_commit_timestamp=on
|
Список | pgsql-hackers |
Fujii Masao <masao.fujii@oss.nttdata.com> writes: > On 2025/07/04 16:29, Hayato Kuroda (Fujitsu) wrote: >> If more GUCs were found which cannot be set during the bootstrap mode, how about >> introducing a new flag like GUC_DEFAULT_WHILE_BOOTSTRAPPING for GUC variables? >> If the flag is set all setting can be ignored when >> IsBootstrapProcessingMode() = true. > If there are many GUCs that behave incorrectly during bootstrap, > a general mechanism like that might be worth considering. But if > only a few GUCs are affected, as I believe is the case, > then such a mechanism may be overkill. As I remarked in the other thread, I don't like inventing a different solution for each GUC. So if there are even two that need something done, I think Hayato-san's idea has merit. The core of the patch could be as little as diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c index 667df448732..43f289924e6 100644 --- a/src/backend/utils/misc/guc.c +++ b/src/backend/utils/misc/guc.c @@ -3464,6 +3464,15 @@ set_config_with_handle(const char *name, config_handle *handle, return 0; } + /* + * Certain GUCs aren't safe to enable during bootstrap mode. Silently + * ignore attempts to set them to non-default values. + */ + if (unlikely(IsBootstrapProcessingMode()) && + (record->flags & GUC_IGNORE_IN_BOOTSTRAP) && + source != PGC_S_DEFAULT) + changeVal = false; + /* * Check if the option can be set at this time. See guc.h for the precise * rules. If we went this way, we'd presumably revert 5a6c39b6d in favor of marking track_commit_timestamp with this flag. regards, tom lane
В списке pgsql-hackers по дате отправления: