Re: Occasional tablespace.sql failures in check-world -jnn

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Occasional tablespace.sql failures in check-world -jnn
Date: 2020-12-09 07:55:04
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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:
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?

Attachment Content-Type Size
regress-tbspace-v1.patch text/x-diff 3.9 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-12-09 08:43:14 A failure of standby to follow timeline switch
Previous Message Andrey Borodin 2020-12-09 07:44:42 pglz compression performance, take two