| 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: | Whole Thread | Raw Message | 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 |