Re: Test to dump and restore objects left behind by regression

On Fri, Dec 27, 2024 at 6:17 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
> > On 20 Dec 2024, at 11:01, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> > On Wed, Dec 18, 2024 at 7:39 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> >>
> >>> On 18 Dec 2024, at 12:28, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
>
> >> + if ( $ENV{PG_TEST_EXTRA}
> >> + && $ENV{PG_TEST_EXTRA} =~ /\bregress_dump_test\b/)
> >> Should this also test that $oldnode and $newnode have matching pg_version to
> >> keep this from running in a cross-version upgrade test? While it can be argued
> >> that running this in a cross-version upgrade is breaking it and getting to keep
> >> both pieces, it's also not ideal to run a resource intensive test we know will
> >> fail. (It can't be done at this exact callsite, just picked to illustrate.)
> >
> > You already wrote it in parenthesis. At the exact callsite $oldnode
> > and $newnode can not be of different versions. In fact newnode is yet
> > to be created at this point. But $oldnode has the same version as the
> > server run from the code. In a cross-version upgrade this test will
> > not be executed. I am confused as to what this comment is about.
>
> Sure, it can't be checked until $newnode is created, but it seems like a cheap
> test to ensure it's not executed as part of someones cross-version tests.

Hmm. The new node is always the node created with the version of code.
It's the old node which may have a different version. Hence I added
code to compare the versions of source node (which is the oldnode) and
destination node (which is created the same way as the new node and
hence has the same version as the new node) in
test_regression_dump_restore() itself. Additionally the code makes
sure that the oldnode doesn't use a custom install path. This is 0002
patch. 0001 in this patchset is 0001 + 0002 in the earlier patch set.

--
Best Wishes,
Ashutosh Bapat