Horton

Re: A assert failure when initdb with track_commit_timestamp=on

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Andy Fan <zhihuifan1213@163.com>, "'Michael Paquier'" <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-07-05T17:23:13Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Disable commit timestamps during bootstrap

Fujii Masao <masao.fujii@oss.nttdata.com> writes:
> On 2025/07/05 2:17, Tom Lane wrote:
>> 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?

It just seemed to go with the bootstrap-mode setting.  But your
example shows differently:

> 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?

Yeah, we should do it like that (and probably also have a comment...)

> 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.

BTW, I now realize that this is only an issue starting from v16.
Before that initdb didn't have a -c switch, so there was not a
way for people to shove random settings into it.

			regards, tom lane