RE: A assert failure when initdb with track_commit_timestamp=on - Mailing list pgsql-hackers

Dear Fujii-san,

> By the way, although it's a separate issue, I noticed that running
> initdb -c transaction_timeout=1 causes an assertion failure:

I feel it may be able to discuss in other places but let me say one comment.

> running bootstrap script ... TRAP: failed Assert("all_timeouts_initialized"), File:
> "timeout.c", Line: 164, PID: 22057
> 0   postgres                            0x00000001105d9d02
> ExceptionalCondition + 178
> 1   postgres                            0x0000000110612af7
> enable_timeout + 55
> 2   postgres                            0x0000000110612aa9
> enable_timeout_after + 73
> 3   postgres                            0x000000010fead8e0
> StartTransaction + 816
> 4   postgres                            0x000000010fead4a1
> StartTransactionCommand + 65
> 5   postgres                            0x000000010fef01de
> BootstrapModeMain + 1518
> 6   postgres                            0x0000000110167ef4 main + 676
> 7   dyld                                0x00007ff805092530 start + 3056
> child process was terminated by signal 6: Abort trap: 6
>
> This happens because enable_timeout() tries to activate the transaction
> timeout before InitializeTimeouts() has been called ? in other words,
> the timeout system hasn't been initialized yet. To fix this, we might
> need to forcibly set transaction_timeout to 0 during bootstrap.

If more GUCs were found which cannot be set during the bootstrap mode, how about
introducing a new flag like GUC_DEFAULT_WHILE_BOOTSTRAPPING for GUC variables?
If the flag is set all setting can be ignored when
IsBootstrapProcessingMode() = true.

Best regards,
Hayato Kuroda
FUJITSU LIMITED