Re: A assert failure when initdb with track_commit_timestamp=on

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

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-05T18:00:07Z

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 →

Disable commit timestamps during bootstrap
- 8bca4476f9f9 13.22 landed
- b61ddcaf41cf 14.19 landed
- dcbbd43317c0 15.14 landed
- 7e7059abfd22 16.10 landed
- ae20c105f0b2 17.6 landed
- 29a4b63c6bc8 18.0 landed
- 5a6c39b6df33 19 (unreleased) landed

Attachments

v1-disallow-setting-some-GUCs-in-bootstrap.patch (text/x-diff) patch v1

I wrote:
> Fujii Masao <masao.fujii@oss.nttdata.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.)

			regards, tom lane