Re: pgsql: pg_upgrade: Check version of target cluster binaries

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: pg_upgrade: Check version of target cluster binaries
Date: 2021-03-04 07:24:07
Message-ID: 77730672-d721-d4e9-5e3e-4c6614ac37fe@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers

On 04.03.21 01:06, Daniel Gustafsson wrote:
>> On 3 Mar 2021, at 23:04, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>> On 3/3/21 3:28 PM, Tom Lane wrote:
>>>> Crake says this patch broke its cross-version upgrade tests:
>>
>>> The log says:
>>> check for
>>> "/home/andrew/bf/root/upgrade.crake/REL9_2_STABLE/inst/bin/postgres"
>>> failed: incorrect version: found "postgres (PostgreSQL) 9.2.24",
>>> expected "postgres (PostgreSQL) 14devel"
>>> But that makes no sense at all. Looks like we're confusing the source and the target.
>>
>> On looking closer, I think the patch is just several bricks shy of a
>> load. It's applying validate_exec (which insists on a match to its
>> own version number) to *both* the source and target binaries. It
>> must not check the source that way.
>
> It's much to late to focus here at the moment, I will take a look in the
> morning unless beaten to it.

I think the attached would be a sensible fix.

Attachment Content-Type Size
0001-pg_upgrade-Fix-oversight-in-version-checking.patch text/plain 4.6 KB

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Daniel Gustafsson 2021-03-04 08:32:23 Re: pgsql: pg_upgrade: Check version of target cluster binaries
Previous Message Daniel Gustafsson 2021-03-04 00:06:36 Re: pgsql: pg_upgrade: Check version of target cluster binaries