Re: Test to dump and restore objects left behind by regression - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Test to dump and restore objects left behind by regression
Date
Msg-id ZmD2xoIa2-MJqMGs@paquier.xyz
Whole thread Raw
In response to Re: Test to dump and restore objects left behind by regression  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Responses Re: Test to dump and restore objects left behind by regression
List pgsql-hackers
On Wed, Jun 05, 2024 at 05:09:58PM +0530, Ashutosh Bapat wrote:
> Thanks for the suggestion. I didn't understand the dependency with the
> buildfarm module. Will the new module be used in buildfarm separately? I
> will work on this soon. Thanks for changing CF entry to WoA.

I had some doubts about PGBuild/Modules/TestUpgradeXversion.pm, but
after double-checking it loads dynamically AdjustUpgrade from the core
tree based on the base path where all the modules are:
    # load helper module from source tree
    unshift(@INC, "$srcdir/src/test/perl");
    require PostgreSQL::Test::AdjustUpgrade;
    PostgreSQL::Test::AdjustUpgrade->import;
    shift(@INC);

It would be annoying to tweak the buildfarm code more to have a
different behavior depending on the branch of Postgres tested.
Anyway, from what I can see, you could create a new module with the
dump filtering rules that AdjustUpgrade requires without having to
update the buildfarm code.

> Changing the physical order of column of a child table based on the
> inherited table seems intentional as per MergeAttributes(). That logic
> looks sane by itself. In binary mode pg_dump works very hard to retain the
> column order by issuing UPDATE commands against catalog tables. I don't
> think mimicking that behaviour is the right choice for non-binary dump. I
> agree with your conclusion that we fix it in by fixing the diffs. The code
> to do that will be part of a separate module.

Thanks.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: First draft of PG 17 release notes
Next
From: Heikki Linnakangas
Date:
Subject: Re: [multithreading] extension compatibility