Re: A assert failure when initdb with track_commit_timestamp=on - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: A assert failure when initdb with track_commit_timestamp=on
Date
Msg-id aG3X4lko7kPhaWi9@paquier.xyz
Whole thread Raw
In response to RE: A assert failure when initdb with track_commit_timestamp=on  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
Responses RE: A assert failure when initdb with track_commit_timestamp=on
List pgsql-hackers
On Wed, Jul 09, 2025 at 02:39:22AM +0000, Hayato Kuroda (Fujitsu) wrote:
> +# Some GUCs like track_commit_timestamp cannot be set to non-default value in
> +# bootstrap mode becasue they may cause crash. Ensure settings can be surely
> +# ignored.
> +command_ok(
> +       [
> +               'initdb', "$tempdir/dataXX",
> +               '-c' => 'track_commit_timestamp=on',
> +               '-c' => 'transaction_timeout=200s'
> +       ],
> +       'successful creation with ignored settings');
> +
> ```

I'd suggest to keep them separate across multiple scripts, where they
hold meaning, as one failure may get hidden by the other.
track_commit_timestamp makes sense in the test module commit_ts, we
should select a second location for transaction_timeout if we keep it
at the end.

> But both Andy's patch and mine assume that post-bootstrap transactions can be
> finished within the specified time. Extremely long value is set above but I
> cannot say all machine won't spend 200s here...

A fresh initdb can be longer than this threshold under
CLOBBER_CACHE_ALWAYS, if my memory serves me well.  There are some
machines with a valgrind setup, additionally, that can take some time,
but I am not sure about their timings when it comes to a bootstrap
setup.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: A assert failure when initdb with track_commit_timestamp=on
Next
From: shveta malik
Date:
Subject: Re: Using failover slots for PG-non_PG logical replication