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 | 75d59502-b571-4df8-9269-fd07cee52dd4@oss.nttdata.com обсуждение исходный текст |
Ответ на | 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 |
On 2025/07/05 2:17, Tom Lane wrote: > Fujii Masao <masao.fujii@oss.nttdata.com> writes: >> On 2025/07/05 0:30, Tom Lane wrote: >>> 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. > >> This code seems to assume that the processing mode is switched to bootstrap before >> GUC parameters are processed. But is that actually the case? > > Oh, good point. But there doesn't seem to be any ill effect from > making BootstrapModeMain set BootstrapProcessing a bit earlier. Maybe. But I noticed that your patch also moves the line "IgnoreSystemIndexes = true;" earlier. Why did you make this change? This could cause initdb to fail with a PANIC error when run with ignore_system_indexes=off, like this: $ initdb -D data -c ignore_system_indexes=off ... FATAL: could not open relation with OID 2703 PANIC: cannot abort transaction 1, it was already committed So perhaps "IgnoreSystemIndexes = true;" should be placed after GUCs are processed? Or GUC ignore_system_indexes also should be treated in the same way as transaction_timeout? Regards, -- Fujii Masao NTT DATA Japan Corporation
В списке pgsql-hackers по дате отправления: