Message-ID: <1b796dc7-a873-4249-8c35-7ea7b9772904@vondra.me>
Date: Thu, 2 Apr 2026 13:26:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP
 DATABASE
To: Alexander Lakhin <exclusion@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
 Tomas Vondra <tomas.vondra@enterprisedb.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>
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>
 <3074140.1775074810@sss.pgh.pa.us>
 <f5b9938d-5931-45b2-bec9-de732e292f29@gmail.com>
Content-Language: en-US
From: Tomas Vondra <tomas@vondra.me>
In-Reply-To: <f5b9938d-5931-45b2-bec9-de732e292f29@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/1b796dc7-a873-4249-8c35-7ea7b9772904%40vondra.me>
Precedence: bulk

On 4/2/26 06:00, Alexander Lakhin wrote:
> Hello Tom and Tomas,
> 
> 01.04.2026 23:20, Tom Lane wrote:
>> 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.
> 
> There also were two failures from jay: [1], [2], but yes, widowbird is
> getting more and more consistent in that aspect: [3], probably because
> of the storage (SD card?) degradation.
> 

Jay is a regular machine, 2-core VM hosted at a university, so not very
powerful but was running for years just fine and seems to be healthy.

> Tomas, maybe you could check if the write speed is more or less acceptable
> there?
> 

Will do. I'll wait for the tests to complete on widowbird, and will do
some testing on the storage (it's running from a flash drive, not SD
card, and I saw stuff in dmesg when it was dying in the past - but now
it's clean).

regards

-- 
Tomas Vondra