Re: pgsql: Avoid race in RelationBuildDesc() affecting CREATE INDEX CONCURR

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andrew Dunstan <andrew@dunslane.net>, Andres Freund <andres@anarazel.de>, Tomas Vondra <tomas.vondra@enterprisedb.com>, pgsql-hackers@postgresql.org, pgsql-release@postgresql.org, Noah Misch <noah@leadboat.com>, pgsql-committers@lists.postgresql.org
Date: 2022-02-09T05:44:42Z
Lists: pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> On Tue, Feb 08, 2022 at 05:43:34PM -0800, Andres Freund wrote:
>> It's stamped, not tagged, so we could send out new tarballs. Or we could skip
>> a release number. IIRC we had to do something along those lines before.

> It does not matter now, but the release is stamped and tagged.

Yeah, I see no need to do anything about this on an emergency
basis.

>> What do you mean with detect here?

> Well, we would not be able to see that something is stuck by default,
> but Noah has just answered to my question by mentioning wait_timeout
> in the buildfarm configuration.

The buildfarm's wait_timeout option isn't that helpful here, because
when it triggers, the client just goes belly-up *with no report*.
So even if the CCA animals had it on, you'd not notice unless you
started to wonder why they'd not reported lately.

I think that's a bug that ought to be fixed.  I do agree that
wait_timeout ought to be finite by default, too.

			regards, tom lane



Commits

  1. Fix back-patch of "Avoid race in RelationBuildDesc() ..."

  2. Avoid race in RelationBuildDesc() affecting CREATE INDEX CONCURRENTLY.