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 OSCPR01MB14966C1F12C388E934CBC9E97F549A@OSCPR01MB14966.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: A assert failure when initdb with track_commit_timestamp=on  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: A assert failure when initdb with track_commit_timestamp=on
List pgsql-hackers
Dear Fujii-san, Andy,

> Shouldn't we also add a TAP test to verify that initdb works correctly
> with GUCs marked as GUC_NOT_IN_BOOTSTRAP?

Another place we can put the test is 001_initdb.pl, like:

```
--- a/src/bin/initdb/t/001_initdb.pl
+++ b/src/bin/initdb/t/001_initdb.pl
@@ -331,4 +331,15 @@ command_fails(
        [ 'pg_checksums', '--pgdata' => $datadir_nochecksums ],
        "pg_checksums fails with data checksum disabled");
 
+# 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');
+
```

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

Best regards,
Hayato Kuroda
FUJITSU LIMITED


pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: [PATCH] Prevent replacement of a function if it's used in an index expression and is not IMMUTABLE
Next
From: Michael Paquier
Date:
Subject: Re: A assert failure when initdb with track_commit_timestamp=on