Re: pg_upgrade version check improvements and small fixes

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Dan McGee <dpmcgee(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_upgrade version check improvements and small fixes
Date: 2011-06-24 02:59:46
Message-ID: 201106240259.p5O2xk900637@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dan McGee wrote:
> On Wed, Jun 22, 2011 at 8:54 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >> 0003 is what I really wanted to solve, which was my failure with
> >> pg_upgrade. The call to pg_ctl didn't succeed because the binaries
> >> didn't match the data directory, thus resulting in this:
> >>
> >> The error had nothing to do with "trust" at all; it was simply that I
> >> tried to use 9.0 binaries with an 8.4 data directory. My patch checks
> >> for this and ensures that the -D bindir is the correct version, just
> >> as the -B datadir has to be the correct version.
> >
> > I had not thought about testing if the bin and data directory were the
> > same major version, but you are right that it generates an odd error if
> > they are not.
> >
> > I changed your sscanf format string because the version can be just
> > "9.2dev" and there is no need for the minor version.
> No problem- you're going to know way more about this than me, and I
> was just going off what I saw in my two installed versions and a quick
> look over at the code of pg_ctl to make sure that string was never
> translated.

> On a side note I don't think I ever mentioned to everyone else why
> parsing the version from pg_ctl rather than pg_config was done- this
> is so we don't introduce any additional binary requirements. Tom Lane
> noted in an earlier cleanup series that pg_config is not really needed
> at all in the old cluster, so I wanted to keep it that way, but pg_ctl
> has always been required.

Yes, I looked specifically for that. We could have used pg_controldata
too, but pg_ctl seemed just as good.

> > ? I saw no reason
> > to test if the binary version matches the pg_upgrade version because we
> > already test the cluster version, and we test the cluster version is the
> > same as the binary version.
> Duh. That makes sense. Thanks for getting to these so quickly!
>
> To partially toot my own horn but also show where a user like me
> encountered this, after some packaging hacking, anyone running Arch
> Linux should be able to do a pg_upgrade from here on out by installing
> the postgresql-old-upgrade package
> (http://www.archlinux.org/packages/extra/x86_64/postgresql-old-upgrade/)
> and possible consulting the Arch wiki.

Great.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jun Ishiduka 2011-06-24 04:41:42 Re: Online base backup from the hot-standby
Previous Message Brendan Jurd 2011-06-24 02:56:30 Re: Fwd: Keywords in pg_hba.conf should be field-specific