Horton

Re: A assert failure when initdb with track_commit_timestamp=on

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: 'Fujii Masao' <masao.fujii@oss.nttdata.com>, Andy Fan <zhihuifan1213@163.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2025-07-09T02:45:54Z
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 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