Re: A assert failure when initdb with track_commit_timestamp=on

Andy Fan <zhihuifan1213@163.com>

From: Andy Fan <zhihuifan1213@163.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-07-02T01:38:18Z
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

Attachments

Michael Paquier <michael@paquier.xyz> writes:

Hi,

> On Wed, Jul 02, 2025 at 12:38:01AM +0000, Andy Fan wrote:
>> However this is not true in BootstrapMode, this failure is masked by
>> default because TransactionTreeSetCommitTsData returns fast when
>> track_commit_timestamp is off.
>
> Agreed that there is no point in registering a commit timestamp in
> the cases of a frozen and bootstrap XIDs.  I would recommend to keep
> the assertion in TransactionIdSetCommitTs(), though, that still looks
> useful to me for the many callers of this routine, at least as a
> sanity check.

Yes, The assert also guard the InvalidTransactionId. So I removed this
solution in v2. Another reason for this is: if we allowed
BooststrapTransactionId in the commit_ts, it introduces something new to
this module when initdb with track_commit_timestamp=on. This risk might
be very low, but it can be avoided easily with the another solution. 

>
> I did not check, but usually we apply filters based on
> IsBootstrapProcessingMode() for code paths that we do not want to
> reach while in bootstrap mode.  Could the same be done here?

I think you are right. so I used IsBootstrapProcessingMode in v2.


-- 
Best Regards
Andy Fan