Re: A assert failure when initdb with track_commit_timestamp=on

On Wed, Jul 02, 2025 at 09:03:35AM +0000, Bertrand Drouvot wrote:
> +        * Don't bother to record commit_ts for Booststrap mode.
>
> typo: s/Booststrap/Bootstrap/
>
> Also, grep on "Bootstrap mode" and "bootstrap mode" gives much more occurrences
> for the later, so maybe use "bootstrap mode" instead?
>
> === 2
>
> The FrozenTransactionId case is missing in v2, is that on purpose?

There may be an argument about bypassing the frozen case as well, but
I cannot get excited about that because it can also be very useful to
detect problems as calling this routine with a frozen XID would be
really wrong.  The assert in TransactionIdSetCommitTs() is enough for
this purpose, no need to add something else.  As of now
TransactionTreeSetCommitTsData() is only called with an active XID at
commit, but if somebody has too much imagination in a module..

As a whole I think that the addition of IsBootstrapProcessingMode() in
TransactionTreeSetCommitTsData() is enough.  There may be an argument
about backpatching this change.  However, nobody has complained about
the idea of enabling the commit_ts module while bootstrapping, so I'd
keep it as a HEAD-only thing and be conservative.

A second thing I would suggest is some test coverage, with the
addition of extra => [ '-c', "track_commit_timestamp=on=on" ] in an
init() method called in one of the script tests of
src/test/modules/commit_ts/t.  Just changing 001_base.pl should be
enough to trigger your original failure, making sure that this never
breaks again.
--
Michael