Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 9699D632CB7 for ; Fri, 16 Jul 2010 20:29:06 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 12741-09 for ; Fri, 16 Jul 2010 23:28:59 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 75A8F632C34 for ; Fri, 16 Jul 2010 20:28:59 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o6GNSvqi025505; Fri, 16 Jul 2010 19:28:57 -0400 (EDT) To: bluestar43@gmail.com cc: Scott Marlowe , pgsql-admin@postgresql.org Subject: Re: Stumped by a version conflict. In-reply-to: References: Comments: In-reply-to Patric Michael message dated "Fri, 16 Jul 2010 16:20:45 -0700" Date: Fri, 16 Jul 2010 19:28:57 -0400 Message-ID: <25504.1279322937@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201007/123 X-Sequence-Number: 35142 Patric Michael 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