Re: Extracting cross-version-upgrade knowledge from buildfarm client - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Extracting cross-version-upgrade knowledge from buildfarm client
Date
Msg-id 1408423.1673798470@sss.pgh.pa.us
Whole thread Raw
In response to Re: Extracting cross-version-upgrade knowledge from buildfarm client  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Extracting cross-version-upgrade knowledge from buildfarm client
List 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



pgsql-hackers by date:

Previous
From: Zhang Mingli
Date:
Subject: Code review in dsa.c
Next
From: Zhang Mingli
Date:
Subject: Re: Code review in dsa.c