On 9/19/20 10:43 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
>> On 9/18/20 6:05 PM, Tom Lane wrote:
>>> Done, you should be able to remove @#@ (NONE, bigint) from the
>>> kill list.
>> crake tests pg_upgrade back to 9.2, so I had to mangle those static
>> repos for non-live branches like this:
> Oh, hm. Now that you mention that, I see snapper is testing 9.3
> and 9.4 upgrades too.
>
> It seems like we have these non-kluge fixes available:
>
> 1. Backpatch 9ab5ed419 as far as 9.2. It'd be unusual for us to patch
> out-of-support branches, but it's certainly not without precedent.
>
> 2. Give up testing these upgrade scenarios. Don't like this much;
> even though these branches are out-of-support, they still seem like
> credible upgrade scenarios in the field.
>
> 3. Put back the extra DROP in TestUpgradeXversion.pm. The main
> complaint about this is we'd then have no test of pg_upgrade'ing
> prefix operators, at least not in these older branches (there is
> another such operator in v10 and later). That doesn't seem like
> a huge deal really, since the same-version pg_upgrade test should
> cover it pretty well. Still, it's annoying.
>
> 4. Undo the elimination of numeric_fac() in HEAD. I find this only
> sort of not-a-kluge, but it's a reasonable alternative.
>
> In the last two cases we might as well revert 9ab5ed419.
>
> Personally I think #1 or #3 are the best answers, but I'm having
> a hard time choosing between them.
Here's how cross version upgrade testing works. It uses a cached version of the
binaries and data directory. The cache is only refreshed if there's a buildfarm
run on that branch. If not, the cached version will just sit there till kingdom
come. So all this should normally need for the non-live branches is a one-off
adjustment in the cached version of the regression database along the lines I
have indicated. My cached versions of 9.2 and 9.3 are two years old.
There are two things you need to do to enable fixing this as I suggested:
* create the socket directory set in the postgresql.conf
* set LD_LIBRARY_PATH to point to the lib directory
Then after starting up musing pg_ctl you can do something like:
bin/psql -h /tmp/buildfarm-xxxxxx -U buildfarm regression
and run the updates.
As I say this should be a one-off operation.
Of course, if you rebuild the cached version then you would need to
repeat the operation. If we think that's too onerous then we could
backpatch these changes, presumably all the way back to 8.4 in case
anyone wants to test back that far.
But another alternative would be to have the buildfarm module run (on
versions older than 9.5):
drop operator @#@ (NONE, bigint);
CREATE OPERATOR @#@ (
PROCEDURE = factorial,
RIGHTARG = bigint
);
On reflection I think that's probably the simplest solution. It will avoid any
surprises if the cached version is rebuilt, and at the same time preserve
testing the prefix operator.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
