| From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Andy Fan <zhihuifan1213(at)163(dot)com>, 'Michael Paquier' <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: A assert failure when initdb with track_commit_timestamp=on |
| Date: | 2025-07-08 08:08:08 |
| Message-ID: | 7547e524-bf5f-45ef-bcbc-59bc55dae8be@oss.nttdata.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2025/07/06 3:00, Tom Lane wrote:
> I wrote:
>> Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> writes:
>>> Or GUC ignore_system_indexes also should be treated in the same way
>>> as transaction_timeout?
>
>> Yes, I'd say we ought to mark that GUC as don't-accept-in-bootstrap
>> too. I've not done any research about what other GUCs can break
>> initdb, but now I'm starting to suspect there are several.
>
> Here's a fleshed-out implementation of Hayato-san's idea. I've
> not done anything about reverting 5a6c39b6d, nor have I done any
> checks to see if there are other GUCs we ought to mark similarly.
> (But at this point I'd be prepared to bet that there are.)
Thanks for the patch! It looks good to me.
Shouldn't we also add a TAP test to verify that initdb works correctly
with GUCs marked as GUC_NOT_IN_BOOTSTRAP?
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Evgeny | 2025-07-08 08:28:33 | Re: Elimination of the repetitive code at the SLRU bootstrap functions. |
| Previous Message | jian he | 2025-07-08 07:48:07 | Re: array_random |