Re: A assert failure when initdb with track_commit_timestamp=on

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-05 16:57:36
Message-ID: 75d59502-b571-4df8-9269-fd07cee52dd4@oss.nttdata.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2025/07/05 2:17, Tom Lane wrote:
> Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jianghua Yang 2025-07-05 16:58:09 Re: [PATCH] initdb: Treat empty -U argument as unset username
Previous Message Alexander Lakhin 2025-07-05 16:00:00 024_add_drop_pub.pl might fail due to deadlock