public inbox for [email protected]
help / color / mirror / Atom feedFrom: Andres Freund <[email protected]>
To: Tom Lane <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Nathan Bossart <[email protected]>
Cc: Greg Sabino Mullane <[email protected]>
Cc: [email protected]
Cc: [email protected]
Subject: Re: optimize file transfer in pg_upgrade
Date: Tue, 18 Mar 2025 10:12:51 -0400
Message-ID: <egjrbbaielccjecm6js5isonhm64zhcqtsoaynbopncreidtes@y3ysztu2d5v4> (raw)
In-Reply-To: <[email protected]>
References: <CA+TgmobD+yMc_jkmk=Vr0UWm9y8AyRFdH+CLZaCukFUoXpCG2A@mail.gmail.com>
<Z8Ihz3by-r5t1m30@nathan>
<Z8ipQBLNySj8e7WD@nathan>
<CAKAnmmJhiSkOvQR1eNkW3-jmdz96gbMvO6tjva-9qAO0OzvQ5A@mail.gmail.com>
<Z8kJveW4yBOI7Jtx@nathan>
<Z9h5Spp76EBygyEL@nathan>
<CA+TgmoZmffymTYV52+a6QFYMAnLe-v4U_P-yqwxqJZ38Hc_Qww@mail.gmail.com>
<Z9iGZ14YlMGZwBnw@nathan>
<CA+TgmoahvU4XX+BWDCYnDD29Qpkd3TJydUJtNc7krLmhSXcgpA@mail.gmail.com>
<[email protected]>
Hi,
On 2025-03-18 10:04:41 -0400, Tom Lane wrote:
> Robert Haas <[email protected]> writes:
> > I'm not quite sure what the best thing is to do is for the pg_upgrade
> > tests in particular, and it may well be best to do as you propose for
> > now and figure that out later. But I question whether just rerunning
> > all of those tests with several different mode flags is the right
> > thing to do. Why for example does 005_char_signedness.pl need to be
> > checked under both --link and --clone? I would guess that there are
> > one or maybe two tests in src/bin/pg_upgrade/t that needs to test
> > --link and --clone and they should grow internal loops to do that
> > (when supported by the local platform) and PG_UPGRADE_TEST_MODE should
> > go in the garbage.
>
> +1
>
> I'd be particularly allergic to running 002_pg_upgrade.pl multiple
> times, as that's one of our most expensive tests, and I flat out
> don't believe that expending that many cycles could be justified.
> Surely we can test these modes sufficiently in some much cheaper and
> more targeted way.
+1
It's useful to have coverage of as many object types as possible in pg_upgrade
- hence 002_pg_upgrade.pl. It helps us to find problems in new code that
didn't think about pg_upgrade.
But that doesn't mean that it's a good idea to run all other pg_upgrade tests
the same way, to the contrary - the cost is too high.
Even leaving runtime aside, I have a hard time believing that --link, --clone,
--swap benefit from running the same way as 002_pg_upgrade.pl - the
implementation of those flags is on a lower level and works the same across
e.g. different index AMs.
I'd go so far as to say that 002_pg_upgrade.pl style testing actually makes it
*harder* to diagnose problems related to things like --link, because there are
no targeted tests, but just a huge set of things that maybe allow to infer
some bug if you spend a lot of time.
Greetings,
Andres Freund
view thread (35+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: optimize file transfer in pg_upgrade
In-Reply-To: <egjrbbaielccjecm6js5isonhm64zhcqtsoaynbopncreidtes@y3ysztu2d5v4>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox