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

From Hayato Kuroda (Fujitsu)
Subject RE: A assert failure when initdb with track_commit_timestamp=on
Date
Msg-id OSCPR01MB14966B0564CF86AC75B470714F549A@OSCPR01MB14966.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: A assert failure when initdb with track_commit_timestamp=on  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [PATCH] Add support for displaying database service in psql prompt
Next
From: shveta malik
Date:
Subject: Re: Improve pg_sync_replication_slots() to wait for primary to advance