Re: A assert failure when initdb with track_commit_timestamp=on

Michael Paquier <michael(at)paquier(dot)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