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 →
-
Disable commit timestamps during bootstrap
- 8bca4476f9f9 13.22 landed
- b61ddcaf41cf 14.19 landed
- dcbbd43317c0 15.14 landed
- 7e7059abfd22 16.10 landed
- ae20c105f0b2 17.6 landed
- 29a4b63c6bc8 18.0 landed
- 5a6c39b6df33 19 (unreleased) landed
Attachments
- v2-0001-Don-t-record-commit_ts-in-bootstarp-mode.patch (text/x-diff)
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