From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robins Tharakan <tharakan@gmail.com>
cc: Andres Freund <andres@anarazel.de>, Thomas Munro <thomas.munro@gmail.com>,
        Peter Eisentraut <peter@eisentraut.org>, Sam James <sam@gentoo.org>,
        pgsql-bugs@lists.postgresql.org
Subject: Re: Build failure with GCC 15 (defaults to -std=gnu23)
In-reply-to: 
 <CAEP4nAxMtdyj7xtrf_fPNj8qU0bprOR=fDiCc154_UhQyUZ5cA@mail.gmail.com>
References: <485f5982-18c5-4210-9c7d-7c05453f7033@eisentraut.org>
 <CA+hUKGL0LWK7hVO9r2eb3hFDBptZByOkAKGAjXKJ5mqd9hs_fA@mail.gmail.com>
 <1447160.1732565223@sss.pgh.pa.us>
 <CA+hUKG+5ErSyS2+rqx0bvKAWadP9NQBOsUgZVpz74ZB0DA=nJw@mail.gmail.com>
 <1578470.1732587191@sss.pgh.pa.us>
 <CA+hUKGJ4HEntEJkpqinyaLn3AfXMvCirWk0n2H4LWDxSSGh-Dw@mail.gmail.com>
 <CA+hUKG+y2q0dP=g=bbkAWD66unrSKsQEc29ERvA_6fTC3b954Q@mail.gmail.com>
 <1897695.1732732104@sss.pgh.pa.us>
 <eu34f6armrlbq7cdai3dy45576h3qybme47uxens4cowpghzqe@52owmagijfiu>
 <2gao2zapw2dumahxgma4t3c6cquy4vnjs5bt4yvduexpywwm2m@3uhxxc63xvlq>
 <CAEP4nAw4UHSgcHFL7Rsub0nCHW=6ZCrpiuBUT_dV5+4apS=Q5Q@mail.gmail.com>
 <494522.1732894313@sss.pgh.pa.us>
 <CAEP4nAyRfWZ8T8xzNHHy4p8kLCrXAAY7Hbs2_P8YCOJiu=6SCA@mail.gmail.com>
 <970389.1734052913@sss.pgh.pa.us>
 <CAEP4nAyOKW+CLHrFDHw1e6fjEG+urL2x1DSeFiU8vnaGsOrV1g@mail.gmail.com>
 <CAEP4nAzOaY0PR-7_t6aN-Dwq6vZzO3i0JAAx2BBRUzy3LwtNGw@mail.gmail.com>
 <CAEP4nAxMtdyj7xtrf_fPNj8qU0bprOR=fDiCc154_UhQyUZ5cA@mail.gmail.co!
 m>
Comments: In-reply-to Robins Tharakan <tharakan@gmail.com>
	message dated "Fri, 13 Dec 2024 13:01:21 +1030"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <986007.1734061333.1@sss.pgh.pa.us>
Date: Thu, 12 Dec 2024 22:42:13 -0500
Message-ID: <986008.1734061333@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/986008.1734061333%40sss.pgh.pa.us>
Precedence: bulk

Robins Tharakan <tharakan@gmail.com> writes:
> Is it possible that 2 concurrent runs (of different branches) could step on
> each other?

Looks that way, doesn't it?  But I suspect it's just a timing
problem --- perhaps one triggered by the background load caused
by another test run, but not directly related to it.  Looking at
019_replslot_limit.pl, I see

-----
# freeze walsender and walreceiver. Slot will still be active, but walreceiver
# won't get anything anymore.
kill 'STOP', $senderpid, $receiverpid;
$node_primary3->advance_wal(2);
-----

This fragment seems to assume that the effect of the kill 'STOP'
is instantaneous.  If it's not, it seems possible that the
walsender process could manage to push out the WAL data added by
"advance_wal" before it gets frozen, in which case the subsequent
loop that's watching for it to get killed would watch in vain,
which matches your symptoms.

As far as a quick grep finds, this is the only test we have that
relies on kill 'STOP'.  I suspect that it's too clever for its
own good.

I trawled the last three months' worth of buildfarm logs and
didn't find any other matches to "not ok 19 - walsender termination
logged".  So this is a pretty improbable failure mode, whatever
the explanation is.

			regards, tom lane