Re: A assert failure when initdb with track_commit_timestamp=on
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Andy Fan <zhihuifan1213@163.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-07-05T01:21:00Z
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
On Fri, Jul 04, 2025 at 11:30:17AM -0400, Tom Lane wrote: > As I remarked in the other thread, I don't like inventing a different > solution for each GUC. So if there are even two that need something > done, I think Hayato-san's idea has merit. > > + /* > + * Certain GUCs aren't safe to enable during bootstrap mode. Silently > + * ignore attempts to set them to non-default values. > + */ > + if (unlikely(IsBootstrapProcessingMode()) && > + (record->flags & GUC_IGNORE_IN_BOOTSTRAP) && > + source != PGC_S_DEFAULT) > + changeVal = false; > + > /* > * Check if the option can be set at this time. See guc.h for the precise > * rules. This is assuming that the default value assigned to a GUC will always take the right decision in the bootstrap case, which is perhaps OK anyway in most cases, or we would know about that during initdb. I'd be OK with something among these lines, yes. I have doubts if we can really safely place the initial GUC loading to happen after the postmaster is switched to bootstrap mode, and if it's a viable strategy in the long-term.. > If we went this way, we'd presumably revert 5a6c39b6d in favor > of marking track_commit_timestamp with this flag. Makes sense, on HEAD. -- Michael