Re: A assert failure when initdb with track_commit_timestamp=on
От
Fujii Masao
Тема
Re: A assert failure when initdb with track_commit_timestamp=on
Дата
Msg-id
ac5d452d-7e9d-4643-b9e7-cb3423b04365@oss.nttdata.com
Ответ на
Список
Дерево обсуждения
Re: A assert failure when initdb with track_commit_timestamp=on Tom Lane <tgl@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 Tom Lane <tgl@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 Tom Lane <tgl@sss.pgh.pa.us>
Re: A assert failure when initdb with track_commit_timestamp=on Tom Lane <tgl@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 "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Re: A assert failure when initdb with track_commit_timestamp=on Michael Paquier <michael@paquier.xyz>
RE: A assert failure when initdb with track_commit_timestamp=on "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Re: A assert failure when initdb with track_commit_timestamp=on Andy Fan <zhihuifan1213@163.com>
On 2025/07/05 0:30, Tom Lane wrote: > Fujii Masao 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. This code seems to assume that the processing mode is switched to bootstrap before GUC parameters are processed. But is that actually the case? Regards, -- Fujii Masao NTT DATA Japan Corporation
В списке pgsql-hackers по дате отправления
От: Fujii Masao
Дата: