Re: Stumped by a version conflict.

Thank you Tom, and I do agree in theory, but I am still unconvinced that
something else isnt amiss because I do recall having to rewrite the web
scripts which access the database, after I upgraded. Seems there was a
change where an empty field no longer returned a zero but a null (or vice
versa) when pg_python performed a SELECT * statement. It is that little bit
that makes me wonder if is somehow still possible that the database was in
fact initialized with 8.1 despite reporting 7.4...

Is there any way for me to tell *without* postmaster or psql running, aside
from the contents of PG_VERSION?

Patric

On Fri, Jul 16, 2010 at 4:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Patric Michael <bluestar43(at)gmail(dot)com> writes:
> > HI Scott. I think if anything, the reverse is true. It is entirely
> > possible that I started 7.4 in a different directory by hand and that the
> > 7.4 server had been running all this time. Since I can't find any other
> > instances pf pg_ctl, I may well have deleted the old tree afterward as
> Craig
> > suggested. (And with me being unaware that it was the old version running
> > and not the new.)
>
> Yeah, I too think that Craig's theory is the most likely explanation,
> if you're sure there is no 7.4 executable to be found on the machine.
> On most modern Unixen it's perfectly possible for an existing process to
> continue to run an executable that's been deleted from the filesystem.
>
> > My only concern at this point, and the one that makes me hesitate, is
> > wondering whether or not the current database is somehow erroneously
> > reporting itself as 7.4 when it is in fact 8.1.
>
> Pretty much impossible --- the version number is compiled into the
> executable at build time.
>
> > Is there any other means
> > aside from PG_VERSION for the binaries to determine which database
> structure
> > was initialized?
>
> The PG_VERSION files contain a human-readable version number, but there
> is also a "catalog version number" stored in the pg_control file. You
> might try pg_controldata for an additional check on whether the
> executables you have at hand match the database, but it seems pretty
> clear they don't :-(
>
> regards, tom lane
>