Re: Stumped by a version conflict.

[Patric Michael <bluestar43@xxxxxxxxx>]

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@xxxxxxxxxxxxx> wrote:

Patric Michael <bluestar43@xxxxxxxxx> 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