Horton

Re: A assert failure when initdb with track_commit_timestamp=on

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
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-05T02:24:38Z
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

Michael Paquier <michael@paquier.xyz> writes:
> 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.

Yeah, I've been wondering about whether the code ought to accept
source == PGC_S_DYNAMIC_DEFAULT.  It doesn't matter until/unless
we need to set this flag on a GUC that has code to compute a
dynamic default, so any decision we made right now would be made
in a vacuum ... but perhaps the right guess is to allow it.

>> If we went this way, we'd presumably revert 5a6c39b6d in favor
>> of marking track_commit_timestamp with this flag.

> Makes sense, on HEAD.

Well, you back-patched 5a6c39b6d, so it's not clear to me why
we wouldn't want to back-patch something to fix any other GUC
suffering from a comparable problem.  I don't see that adding
another possible GUC flag is an ABI break, especially when it's
a flag that no extension could have a need to set.

			regards, tom lane