Re: Occasional tablespace.sql failures in check-world -jnn
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org
Date: 2020-12-09T07:55:04Z
Lists: pgsql-hackers
Attachments
- regress-tbspace-v1.patch (text/x-diff) patch v1
On Tue, Dec 08, 2020 at 05:29:11PM -0800, Andres Freund wrote: > I suspect this is related to the pg_upgrade test and the main regression > test running at the same time. We have the following in > src/test/regress/GNUMakefile. Yes, this one is not completely new to -hackers. See patch 0002 here that slightly touched the topic by creating a specific makefile rule, but I never got back to it as I never got annoyed by this problem: https://www.postgresql.org/message-id/20200511.171354.514381788845037011.horikyota.ntt@gmail.com What we have here is not a solution though... > It's not clear to me why we have this logic in the makefile at all? > Somebody taught pg_regress to do so, but only on windows... See > convert_sourcefiles_in(). ... Because we may still introduce this problem again if some new stuff uses src/test/pg_regress in a way similar to pg_upgrade, triggering again tablespace-setup. Something like the attached may be enough, though I have not spent much time checking the surroundings, Windows included. > The other thing that confuses me is why I started getting that error in > *multiple* branches recently, even though I have used the parallel > check-world for ages. Perhaps you have just increased -j lately or moved to a faster machine where there are higher changes of collision? -- Michael
Commits
-
Move tablespace path re-creation from the makefiles to pg_regress
- 6c788d9f6aad 14.0 landed