Dan McGee wrote: > On Wed, Jun 22, 2011 at 8:54 PM, Bruce Momjian <br...@momjian.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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers