Horton

Re: Extracting cross-version-upgrade knowledge from buildfarm client

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Michael Paquier <michael@paquier.xyz>, pgsql-hackers@lists.postgresql.org
Date: 2023-01-15T16:01:10Z
Lists: pgsql-hackers 
Andrew Dunstan <andrew@dunslane.net> writes:
> On 2023-01-14 Sa 15:06, Tom Lane wrote:
>> Here's version 2, incorporating your suggestions and with some
>> further work to make it handle 9.2 fully.

> This looks pretty good to me.

Great!  I'll work on making back-branch versions.

> I'll probably change this line
>    my $adjust_cmds = adjust_database_contents($oversion, %dbnames);
> so it's only called if the old and new versions are different. Is there
> any case where a repo shouldn't be upgradeable to its own version
> without adjustment?

Makes sense.  I'd keep the check for $oversion eq 'HEAD' in the
subroutines, but that's mostly just to protect the version
conversion code below it.

Another thing I was just thinking about was not bothering to run
"diff" if the fixed dump strings are equal in-memory.  You could
take that even further and not write out the fixed files at all,
but that seems like a bad idea for debuggability of the adjustment
subroutines.  However, I don't see why we need to write an
empty diff file, nor parse it.

One other question before I continue --- do the adjustment
subroutines need to worry about Windows newlines in the strings?
It's not clear to me whether Perl will automatically make "\n"
in a pattern match "\r\n", or whether it's not a problem because
something upstream will have stripped \r's.

			regards, tom lane

Commits

  1. Compare only major versions in AdjustUpgrade.pm

  2. Get rid of the "new" and "old" entries in a view's rangetable.

  3. Create common infrastructure for cross-version upgrade testing.