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. > 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. -Dan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers