On Wed, Jun 22, 2011 at 8:54 PM, Bruce Momjian <bruce@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
