Horton

RE: A assert failure when initdb with track_commit_timestamp=on

Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>

View thread
From: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
To: 'Michael Paquier' <michael@paquier.xyz>
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-09T04:41:59Z
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

Dear Michael,

> 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.

OK, so track_commit_timestamp can be tested like what initially did:

```
--- a/src/test/modules/commit_ts/t/001_base.pl
+++ b/src/test/modules/commit_ts/t/001_base.pl
@@ -11,8 +11,7 @@ use Test::More;
 use PostgreSQL::Test::Cluster;
 
 my $node = PostgreSQL::Test::Cluster->new('foxtrot');
-$node->init;
-$node->append_conf('postgresql.conf', 'track_commit_timestamp = on');
+$node->init(extra => [ '-c', 'track_commit_timestamp=on' ]);
 $node->start;
```

> 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.

Hmm. So I felt that we should not add tests for transaction_timeout for such a slow
environment. Thought?

Best regards,
Hayato Kuroda
FUJITSU LIMITED