From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Extracting cross-version-upgrade knowledge from buildfarm client |
Date: | 2023-01-14 20:06:06 |
Message-ID: | 1199696.1673726766@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> OK, I'll take a look at that and make a new draft.
Here's version 2, incorporating your suggestions and with some
further work to make it handle 9.2 fully. I think this could
be committable so far as HEAD is concerned, though I still
need to make versions of AdjustUpgrade.pm for the back branches.
I tried to use this to replace upgrade_adapt.sql, but failed so
far because I couldn't figure out exactly how you're supposed
to use 002_pg_upgrade.pl with an old source installation.
It's not terribly well documented. In any case I think we
need a bit more thought about that, because it looks like
002_pg_upgrade.pl thinks that you can supply any random dump
file to serve as the initial state of the old installation;
but neither what I have here nor any likely contents of
upgrade_adapt.sql or the "custom filter" rules are going to
work on databases that aren't just the standard regression
database(s) of the old version.
I assume we should plan on reverting 9814ff550 (Add custom filtering
rules to the TAP tests of pg_upgrade)? Does that have any
plausible use that's not superseded by this patchset?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
adjustupgrade-2.patch | text/x-diff | 17.7 KB |
xversion-2.patch | text/x-diff | 10.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-01-14 20:34:03 | Re: Improve WALRead() to suck data directly from WAL buffers when possible |
Previous Message | Jeff Davis | 2023-01-14 20:03:48 | Re: Rework of collation code, extensibility |