Horton

Re: A assert failure when initdb with track_commit_timestamp=on

Fujii Masao <masao.fujii@oss.nttdata.com>

View thread
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
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-05T16:57:36Z
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


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