Re: Stumped by a version conflict.
От | Patric Michael |
---|---|
Тема | Re: Stumped by a version conflict. |
Дата | |
Msg-id | AANLkTilfpzhbaeZAZdEbw8nj0IERKAsBUUASm5usgurX@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Stumped by a version conflict. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Stumped by a version conflict.
Re: Stumped by a version conflict. |
Список | pgsql-admin |
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
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@sss.pgh.pa.us> wrote:
Patric Michael <bluestar43@gmail.com> writes:Yeah, I too think that Craig's theory is the most likely explanation,
> 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.)
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.Pretty much impossible --- the version number is compiled into the
> 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.
executable at build time.The PG_VERSION files contain a human-readable version number, but there
> Is there any other means
> aside from PG_VERSION for the binaries to determine which database structure
> was initialized?
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
В списке pgsql-admin по дате отправления: