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
-
Fix back-patch of "Avoid race in RelationBuildDesc() ..."
- eac3c4007044 10.21 landed
- 3cc89d9c3834 11.16 landed
- 2d96a66c2eef 12.11 landed
- 1b8462bf1d09 13.7 landed
-
Avoid race in RelationBuildDesc() affecting CREATE INDEX CONCURRENTLY.
- fdd965d074d4 15.0 cited