Message-ID: <700055c2-e5e9-6d00-09cf-5b9666a1d17b@dunslane.net>
Date: Sat, 14 Jan 2023 09:49:12 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: Extracting cross-version-upgrade knowledge from buildfarm client
Content-Language: en-US
To: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org
References: <891521.1673657296@sss.pgh.pa.us>
From: Andrew Dunstan <andrew@dunslane.net>
In-Reply-To: <891521.1673657296@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/700055c2-e5e9-6d00-09cf-5b9666a1d17b%40dunslane.net>
Precedence: bulk


On 2023-01-13 Fr 19:48, Tom Lane wrote:
> This is a followup to the discussion at [1], in which we agreed that
> it's time to fix the buildfarm client so that knowledge about
> cross-version discrepancies in pg_dump output can be moved into
> the community git tree, making it feasible for people other than
> Andrew to fix problems when we change things of that sort.
> The idea is to create helper files that live in the git tree and
> are used by the BF client to perform the activities that are likely
> to need tweaking.
>
> Attached are two patches, one for PG git and one for the buildfarm
> client, that create a working POC for this approach.  I've only
> carried this as far as making a helper file for HEAD, but I believe
> that helper files for the back branches would mostly just need to
> be cut-down versions of this one.  I've tested it successfully with
> cross-version upgrade tests down to 9.3.  (9.2 would need some more
> work, and I'm not sure if it's worth the trouble --- are we going to
> retire 9.2 soon?)
>
> I'm a very mediocre Perl programmer, so I'm sure there are stylistic
> and other problems, but I'm encouraged that this seems feasible.
>
> Also, I wonder if we can't get rid of
> src/bin/pg_upgrade/upgrade_adapt.sql in favor of using this code.
> I tried to write adjust_database_contents() in such a way that it
> could be pointed at a database by some other Perl code that's
> not the buildfarm client.
>
> 			regards, tom lane
>
> [1] https://www.postgresql.org/message-id/951602.1673535249%40sss.pgh.pa.us


OK, we've been on parallel tracks (sorry about that). Let's run with
yours, as it covers more ground.

One thing I would change is that your adjust_database_contents tries to
make the adjustments rather than passing back a set of statements. We
could make that work, although your attempt won't really work for the
buildfarm, but I would just make actually performing the adjustments the
client's responsibility. That would make for much less disturbance in
the buildfarm code.

I also tried to remove a lot of the ugly release tag processing,
leveraging our PostgreSQL::Version gadget. I think that's worthwhile too.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com