From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Justin Pryzby <pryzby@telsasoft.com>, Robert Haas <robertmhaas@gmail.com>,
        Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers@postgresql.org,
        Thomas Munro <thomas.munro@gmail.com>,
        Melanie Plageman <melanieplageman@gmail.com>,
        Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
        Daniel Gustafsson <daniel@yesql.se>
Subject: Re: Adding CI to our tree
In-reply-to: <20220119041646.rhuo3youiqxqjmo2@alap3.anarazel.de>
References: <20220114235457.GQ14051@telsasoft.com>
 <87a81b91-87bf-c0bc-7e4f-06dffadcf737@dunslane.net>
 <20220117181946.bmvubqpzqxlvmgeh@alap3.anarazel.de>
 <CA+Tgmoap6WXzta=zw97SF73hCfzEWVMtfDFB01svYXMtTzKVVA@mail.gmail.com>
 <20220117192510.txue5mihjaxlngep@alap3.anarazel.de>
 <85428.1642447853@sss.pgh.pa.us>
 <20220117201619.3ltudwhgk2krmoki@alap3.anarazel.de>
 <20220118210847.GC23027@telsasoft.com>
 <20220119011626.nw5cvugqfsy3fyob@alap3.anarazel.de>
 <440239.1642560607@sss.pgh.pa.us>
 <20220119041646.rhuo3youiqxqjmo2@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Tue, 18 Jan 2022 20:16:46 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <450971.1642568052.1@sss.pgh.pa.us>
Date: Tue, 18 Jan 2022 23:54:12 -0500
Message-ID: <450972.1642568052@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/450972.1642568052%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2022-01-18 21:50:07 -0500, Tom Lane wrote:
>> This actually causes parallel check-world to fail altogether on florican's
>> host, because the initial fsync of the recovered primary takes more than 3
>> minutes when there's conflicting I/O traffic, causing pg_ctl to time out.

> Ugh.

I misspoke there: it's the standby that is performing an fsync'd
checkpoint and timing out, during the test's promote-the-standby
step.

This test attempt revealed another problem too: the standby never
shut down, and thus the calling "make" never quit, until I intervened
manually.  I'm not sure why.  I see that Cluster::promote uses
system_or_bail() to run "pg_ctl promote" ... could it be that
BAIL_OUT causes the normal script END hooks to not get run?
But it seems like we'd have noticed that long ago.

			regards, tom lane