From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Lakhin <exclusion@gmail.com>
cc: Michael Paquier <michael@paquier.xyz>,
        =?UTF-8?B?SXdhdGEsIEF5YS/lsqnnlLAg5b2p?= <iwata.aya@fujitsu.com>,
        Peter Smith <smithpb2250@gmail.com>,
        =?UTF-8?B?S3Vyb2RhLCBIYXlhdG8v6buS55SwIOmavOS6ug==?=
 <kuroda.hayato@fujitsu.com>,
        Pavel Stehule <pavel.stehule@gmail.com>,
        Chao Li <li.evan.chao@gmail.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP
 DATABASE
In-reply-to: <fb4028b6-e07f-4d84-a65e-c90bc96e6356@gmail.com>
References: <abev_E-SE94zHP0n@paquier.xyz> <abiUQ5MBGG9MDM1h@paquier.xyz>
 <TYRPR01MB12156CA129F54361D19ECAB56F541A@TYRPR01MB12156.jpnprd01.prod.outlook.com>
 <abjRR1bhoa9N8XEa@paquier.xyz>
 <a99bd177-00e3-4512-ba7c-29e180926467@gmail.com>
 <abkR1aod9_dG-PGM@paquier.xyz> <1020519.1773863522@sss.pgh.pa.us>
 <abtJLEAsf1HZXWdR@paquier.xyz> <ab4Gf2r-Bd6P7BiW@paquier.xyz>
 <f913fba1-da59-404c-9eb3-07c7304be637@gmail.com>
 <acun5kN_JaLFcfq_@paquier.xyz>
 <fb4028b6-e07f-4d84-a65e-c90bc96e6356@gmail.com>
Comments: In-reply-to Alexander Lakhin <exclusion@gmail.com>
	message dated "Tue, 31 Mar 2026 20:00:00 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3074139.1775074810.1@sss.pgh.pa.us>
Date: Wed, 01 Apr 2026 16:20:10 -0400
Message-ID: <3074140.1775074810@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3074140.1775074810%40sss.pgh.pa.us>
Precedence: bulk

Alexander Lakhin <exclusion@gmail.com> writes:
> I think this can explain slow CommitTransactionCommand() and why it
> happens not every time. Regarding other animals, I guess they can
> experience the same bumps but not exceeding 5 seconds (50 tries). Thus,
> from my understanding, for the failure to happen, we need to have slow
> storage and initialize_worker_spi() -> CommitTransactionCommand() reaching
> XLogFileClose().

So, it remains not very clear why only widowbird is showing this
failure, but I think we can safely take away the bottom-line
conclusion that hard-wiring a maximum wait of 5s in
CountOtherDBBackends() was not a great idea.

I don't think I want to propose a GUC for this, but could it make
sense to check for an environment variable, similarly to PGCTLTIMEOUT
and PG_TEST_TIMEOUT_DEFAULT?  Whichever way we do it, it could replace
the existing crude hack to change the max wait in injection-point
mode.

			regards, tom lane