Re: Assertion failure during initdb with transaction_timeout set

On 2025/07/04 23:47, Tom Lane wrote:
> Fujii Masao <masao.fujii@oss.nttdata.com> writes:
>> While discussing the assertion failure with track_commit_timestamp=on during initdb [1],
>> I found a similar issue with another GUC: transaction_timeout.
> 
>> This happens because enable_timeout() tries to start the transaction timeout
>> before InitializeTimeouts() has been called, i.e., the timeout subsystem
>> hasn't been initialized yet.
> 
>> To address this, I'm thinking forcibly setting transaction_timeout to 0
>> during bootstrap or in initdb.
> 
> I don't like inventing a different workaround for each case we find.
> The precedent established by the other patch is to prevent the
> relevant subsystem from starting if IsBootstrapProcessingMode().
> Can't we do something similar here?

One idea is to allow the enable_timeout_xxx() functions to be called before
the timeout mechanism is initialized, similar to how reschedule_timeouts()
handles it. However, this might make it harder to catch bugs where timeouts
are enabled too early in cases where that shouldn't be allowed.

     void
     reschedule_timeouts(void)
     {
        /* For flexibility, allow this to be called before we're initialized. */
        if (!all_timeouts_initialized)
            return;

Another idea is to have the enable_timeout_xxx() functions simply return
immediately when IsBootstrapProcessingMode() is true.

That said, either approach involves adding checks to functions that may be
called frequently, which some might prefer to avoid for performance reasons.

Regards,

-- 
Fujii Masao
NTT DATA Japan Corporation