Content-Type: multipart/alternative;
 boundary="------------0vnBrB7130IX3P2LnxnyXf5L"
Message-ID: <f5b9938d-5931-45b2-bec9-de732e292f29@gmail.com>
Date: Thu, 2 Apr 2026 07:00:00 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP
 DATABASE
To: 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>
Content-Language: en-US
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <3074140.1775074810@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/f5b9938d-5931-45b2-bec9-de732e292f29%40gmail.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------0vnBrB7130IX3P2LnxnyXf5L
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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.

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

Regarding the test-specific fix, let me remind of the other failure from
widowbird: [4].

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jay&dt=2026-03-10%2019%3A26%3A19
[2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jay&dt=2026-03-24%2020%3A43%3A24
[3] https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=widowbird&br=master
[4] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=widowbird&dt=2025-10-25%2010%3A35%3A03

Best regards,
Alexander
--------------0vnBrB7130IX3P2LnxnyXf5L
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Hello Tom and Tomas,<br>
      <br>
      01.04.2026 23:20, Tom Lane wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:3074140.1775074810@sss.pgh.pa.us">
      <pre wrap="" class="moz-quote-pre">Alexander Lakhin <a class="moz-txt-link-rfc2396E" href="mailto:exclusion@gmail.com">&lt;exclusion@gmail.com&gt;</a> writes:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">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() -&gt; CommitTransactionCommand() reaching
XLogFileClose().
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
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.
</pre>
    </blockquote>
    <br>
    There also were two failures from jay: [1], [2], but yes, widowbird
    is<br>
    getting more and more consistent in that aspect: [3], probably
    because<br>
    of the storage (SD card?) degradation.<br>
    <br>
    Tomas, maybe you could check if the write speed is more or less
    acceptable<br>
    there?<br>
    <br>
    Regarding the test-specific fix, let me remind of the other failure
    from<br>
    widowbird: [4].<br>
    <br>
    [1]
<a class="moz-txt-link-freetext" href="https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jay&amp;dt=2026-03-10%2019%3A26%3A19">https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jay&amp;dt=2026-03-10%2019%3A26%3A19</a><br>
    [2]
<a class="moz-txt-link-freetext" href="https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jay&amp;dt=2026-03-24%2020%3A43%3A24">https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jay&amp;dt=2026-03-24%2020%3A43%3A24</a><br>
    [3]
<a class="moz-txt-link-freetext" href="https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=widowbird&amp;br=master">https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=widowbird&amp;br=master</a><br>
    [4]
<a class="moz-txt-link-freetext" href="https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=widowbird&amp;dt=2025-10-25%2010%3A35%3A03">https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=widowbird&amp;dt=2025-10-25%2010%3A35%3A03</a><br>
    <br>
    Best regards,<br>
    Alexander<br>
  </body>
</html>

--------------0vnBrB7130IX3P2LnxnyXf5L--