Stumped by a version conflict.

--0016369fa0b6d73f2e048b88c8f2
Content-Type: text/plain; charset=ISO-8859-1

Hi all...

I joined this list in an effort to solve a puzzle I fail to understand.
Thank you in advance for taking the time to read.

I've been managing a domain for the last eight years as an erstwhile
administrator. Erstwhile meaning it is largely a matter of setting up and
automating the routine functions of the machine. I am not by any stretch of
the imagination a guru. And please keep in mind that aside from minor tweaks
and upgrades, I pretty much leave the machine alone.

In that time, I've upgraded postgres 7.1 to 7.4 and now to 8.1 and have
rarely needed to reboot the machine. (Yay CentOS!) Manual installs from
source. Not RPM's

A few days ago however, the co-lo appears to have taken the system down for
a short time and brought it back up, essentially rebooting the system. No
big deal, except that until then, it had been running for almost two years.

Everything came back up as expected, with the exception of postgres. When I
went to start it manually, I got an error warning of an unrecognized
tcpip_socket parameter in postgresql.conf. Searching the 8.1 manual I
discovered it had been deprecated in favor of listen_addresses. Odd, but
okay.

I commented out the parameter (irrelevant since psql was configured with
defaults anyway) and tried starting it again. The next error I got was that
the database was initialized with version 7.4 and this version was 8.1.
What?

I checked the time stamps of the database I knew to be active, and yes,
there are several timestamps from two days ago so I kow that's the most
recent. PG_VERSION does indeed show 7.4 as the current version, and yet,
the binaries return 8.1.11 as the current version.

It should be noted at this point that medical problems have affected my
memory, so I may well be forgetting something obvious to the rest of you.
:)

So my questions are these: Since 8.1 binaries are the only ones that exist
on the machine, (in /usr/bin) how is it possible that they could have
utilized a database initialized with 7.4 in the first place? I thought
perhaps I started the server back then with an old binary, rather than
what's in the path, but I find no other instances of psql, pg_ctl, etc.
except whats in /bin/.

Without an answer to that, and since I can't start the server as it is
(apparently) currently compiled, I'd have to recompile 7.4, open the
database, dumpall with those binaries, initialize a new database with the
8.1 binaries, and restore the backed up db into the 8.1 structure. But if
the old 7.4 (current) db was running under 8.1 (and I still cant see how
that was possible) will it damage the db structure when it is restored?

Maybe the better question, though probably harder to answer is, "What am I
forgetting?"

Any thoughts or suggestions on how to restart postgres with the database I
know to be current will be especially helpful.

Thank you.

--0016369fa0b6d73f2e048b88c8f2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all...

I=
joined this list in an effort to solve a puzzle I fail to understand.=A0 T=
hank you in advance for taking the time to read.

I've been manag=
ing a domain for the last eight years as an erstwhile administrator.=A0 Ers=
twhile meaning it is largely a matter of setting up and automating the rout=
ine functions of the machine. I am not by any stretch of the imagination a =
guru. And please keep in mind that aside from minor tweaks and upgrades, I =
pretty much leave the machine alone.





In that time, I've upgraded postgres 7.1 to 7.4 and now to 8.1 and =
have rarely needed to reboot the machine. (Yay CentOS!)=A0 Manual installs =
from source.=A0 Not RPM's

A few days ago however, the co-lo appe=
ars to have taken the system down for a short time and brought it back up, =
essentially rebooting the system.=A0 No big deal, except that until then, i=
t had been running for almost two years.





Everything came back up as expected, with the exception of postgres.=A0=
When I went to start it manually, I got an error warning of an unrecognize=
d tcpip_socket parameter in postgresql.conf.=A0 Searching the 8.1 manual I =
discovered it had been deprecated in favor of listen_addresses.=A0 Odd, but=
okay.





I commented out the parameter (irrelevant since psql was configured wit=
h defaults anyway) and tried starting it again.=A0 The next error I got was=
that the database was initialized with version 7.4 and this version was 8.=
1.=A0 What?




I checked the time stamps of the database I knew to be active, and yes,=
there are several timestamps from two days ago so I kow that's the mos=
t recent.=A0 PG_VERSION does indeed show 7.4 as the current version, and ye=
t, the binaries return 8.1.11 as the current version.



It should be noted at this point that medical problems have affected my=
memory, so I may well be forgetting something obvious to the rest of you.=
   :)

So my questions are these:=A0 Since 8.1 binaries are the o=
nly ones that exist on the machine, (in /usr/bin) how is it possible that t=
hey could have utilized a database initialized with 7.4 in the first place?=
=A0 I thought perhaps I started the server back then with an old binary, ra=
ther than what's in the path, but I find no other instances of psql, pg=
_ctl, etc. except whats in /bin/.



Without an answer to that, and since I can't start the server as it=
is (apparently) currently compiled, I'd have to recompile 7.4, open th=
e database, dumpall with those binaries, initialize a new database with the=
8.1 binaries, and restore the backed up db into the 8.1 structure.=A0 But =
if the old 7.4 (current) db was running under 8.1 (and I still cant see how=
that was possible) will it damage the db structure when it is restored?=A0=




Maybe the better question, though probably harder to answer is, "W=
hat am I forgetting?"

Any thoughts or suggestions on how to res=
tart postgres with the database I know to be current will be especially hel=
pful.=A0



Thank you.






--0016369fa0b6d73f2e048b88c8f2--

Re: Stumped by a version conflict.

On 7/16/10 3:31 PM, Patric Michael wrote:
> Hi all...
>
> I joined this list in an effort to solve a puzzle I fail to understand.
> Thank you in advance for taking the time to read.
>
> I've been managing a domain for the last eight years as an erstwhile
> administrator. Erstwhile meaning it is largely a matter of setting up
> and automating the routine functions of the machine. I am not by any
> stretch of the imagination a guru. And please keep in mind that aside
> from minor tweaks and upgrades, I pretty much leave the machine alone.
>
> In that time, I've upgraded postgres 7.1 to 7.4 and now to 8.1 and have
> rarely needed to reboot the machine. (Yay CentOS!) Manual installs from
> source. Not RPM's
>
> A few days ago however, the co-lo appears to have taken the system down
> for a short time and brought it back up, essentially rebooting the
> system. No big deal, except that until then, it had been running for
> almost two years.
>
> Everything came back up as expected, with the exception of postgres.
> When I went to start it manually, I got an error warning of an
> unrecognized tcpip_socket parameter in postgresql.conf. Searching the
> 8.1 manual I discovered it had been deprecated in favor of
> listen_addresses. Odd, but okay.
>
> I commented out the parameter (irrelevant since psql was configured with
> defaults anyway) and tried starting it again. The next error I got was
> that the database was initialized with version 7.4 and this version was
> 8.1. What?
>
> I checked the time stamps of the database I knew to be active, and yes,
> there are several timestamps from two days ago so I kow that's the most
> recent. PG_VERSION does indeed show 7.4 as the current version, and
> yet, the binaries return 8.1.11 as the current version.

Is it possible that you built the Postgres 8.1, then accidentally started the old 7.4 version of Postgres, and then deleted the 7.4 tree? It may have been still running for the last two years on a Postgres 7.4 server.

Craig


>
> It should be noted at this point that medical problems have affected my
> memory, so I may well be forgetting something obvious to the rest of
> you. :)
>
> So my questions are these: Since 8.1 binaries are the only ones that
> exist on the machine, (in /usr/bin) how is it possible that they could
> have utilized a database initialized with 7.4 in the first place? I
> thought perhaps I started the server back then with an old binary,
> rather than what's in the path, but I find no other instances of psql,
> pg_ctl, etc. except whats in /bin/.
>
> Without an answer to that, and since I can't start the server as it is
> (apparently) currently compiled, I'd have to recompile 7.4, open the
> database, dumpall with those binaries, initialize a new database with
> the 8.1 binaries, and restore the backed up db into the 8.1 structure.
> But if the old 7.4 (current) db was running under 8.1 (and I still cant
> see how that was possible) will it damage the db structure when it is
> restored?
>
> Maybe the better question, though probably harder to answer is, "What am
> I forgetting?"
>
> Any thoughts or suggestions on how to restart postgres with the database
> I know to be current will be especially helpful.
>
> Thank you.
>
>


--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Stumped by a version conflict.

On Fri, Jul 16, 2010 at 4:31 PM, Patric Michael wrot=
e:
> Hi all...
>
> I joined this list in an effort to solve a puzzle I fail to understand.
> Thank you in advance for taking the time to read.
>
> I've been managing a domain for the last eight years as an erstwhile
> administrator.=A0 Erstwhile meaning it is largely a matter of setting up =
and
> automating the routine functions of the machine. I am not by any stretch =
of
> the imagination a guru. And please keep in mind that aside from minor twe=
aks
> and upgrades, I pretty much leave the machine alone.
>
> In that time, I've upgraded postgres 7.1 to 7.4 and now to 8.1 and have
> rarely needed to reboot the machine. (Yay CentOS!)=A0 Manual installs from
> source.=A0 Not RPM's
>
> A few days ago however, the co-lo appears to have taken the system down f=
or
> a short time and brought it back up, essentially rebooting the system.=A0=
No
> big deal, except that until then, it had been running for almost two year=
s.
>
> Everything came back up as expected, with the exception of postgres.=A0 W=
hen I
> went to start it manually, I got an error warning of an unrecognized
> tcpip_socket parameter in postgresql.conf.=A0 Searching the 8.1 manual I
> discovered it had been deprecated in favor of listen_addresses.=A0 Odd, b=
ut
> okay.

Is it possible you started 8.1 in a different directory by hand
(pg_ctl -D /my/other/dir start) many years ago and that the default
old install of 7.4 is sitting in the /var/lib/pgsql spot?

--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Stumped by a version conflict.

--0016e64769e4c94fa4048b897800
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jul 16, 2010 at 4:08 PM, Scott Marlowe wrote:

> On Fri, Jul 16, 2010 at 4:31 PM, Patric Michael
> wrote:
>
> >
> > Everything came back up as expected, with the exception of postgres.
> When I
> > went to start it manually, I got an error warning of an unrecognized
> > tcpip_socket parameter in postgresql.conf. Searching the 8.1 manual I
> > discovered it had been deprecated in favor of listen_addresses. Odd, but
> > okay.
>
> Is it possible you started 8.1 in a different directory by hand
> (pg_ctl -D /my/other/dir start) many years ago and that the default
> old install of 7.4 is sitting in the /var/lib/pgsql spot?
>

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.)

Truly, that's the only logical thing I can think of for an explanation.

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. Is there any other means
aside from PG_VERSION for the binaries to determine which database structure
was initialized?

Thank you for your reply.

--0016e64769e4c94fa4048b897800
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

class=3D"gmail_quote">On Fri, Jul 16, 2010 at 4:08 PM, Scott Marlowe dir=3D"ltr"><scott.marlowe@g=
mail.com> wrote:

r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

>On Fri, Jul 16, 2010 at 4:31 PM, Patric Michael < star43@gmail.com">bluestar43@gmail.com> wrote:





>

> Everything came back up as expected, with the exception of postgres.=
=A0 When I

> went to start it manually, I got an error warning of an unrecognized r>
> tcpip_socket parameter in postgresql.conf.=A0 Searching the 8.1 manual=
I

> discovered it had been deprecated in favor of listen_addresses.=A0 Odd=
, but

> okay.

Is it possible you started 8.1 in a different directory by hand

(pg_ctl -D /my/other/dir start) many years ago and that the default

old install of 7.4 is sitting in the /var/lib/pgsql spot?

Re: Stumped by a version conflict.

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

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Stumped by a version conflict.

--AbGtdE3O5mWGIB51
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> 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.

Indeed, but it's not generally a good thing. I'd recommend installing
something which checks for such things and sends a report when found
(uh, openvas is the first thing that comes to mind, but TIGER IDS might
catch these also).

Thanks,

Stephen

--AbGtdE3O5mWGIB51
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkxA8eEACgkQrzgMPqB3kijI+QCgjYf+SsGrRHTo/DLe2wsX qriV
DIIAoJTSlih2tOdVL/0sejA/teEAhi4F
=tTAD
-----END PGP SIGNATURE-----

--AbGtdE3O5mWGIB51--

Re: Stumped by a version conflict.

--0016e6476634abbd7f048b8a22fa
Content-Type: text/plain; charset=ISO-8859-1

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

> 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
>

--0016e6476634abbd7f048b8a22fa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 th=
e database, after I upgraded.=A0 Seems there was a change where an empty fi=
eld no longer returned a zero but a null (or vice versa) when pg_python per=
formed a SELECT * statement.=A0 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, a=
side from the contents of PG_VERSION?

Patric

r>

Re: Stumped by a version conflict.

--4KCu9u4K62DZJFE0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

* Patric Michael (bluestar43@gmail.com) wrote:
> Is there any way for me to tell *without* postmaster or psql running, aside
> from the contents of PG_VERSION?

pg_controldata, as Tom suggested...

Stephen

--4KCu9u4K62DZJFE0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkxA9Q0ACgkQrzgMPqB3kijJLQCfWV+EOeXKFu0Suyh1WE60 MGzN
IJ8Ani3a1rgTwGZHdrDsLM4Yu8q6qjXc
=kUgP
-----END PGP SIGNATURE-----

--4KCu9u4K62DZJFE0--

Re: Stumped by a version conflict.

On Fri, Jul 16, 2010 at 6:08 PM, Patric Michael wrot=
e:
> 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.=A0 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.=A0 It is that littl=
e bit
> that makes me wonder if is somehow still possible that the database was in
> fact initialized with 8.1 despite reporting 7.4...

So what does

sudo locate postgresql.conf

say?

--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: Stumped by a version conflict.

--0016369f9d172b46ba048b8e5ea8
Content-Type: text/plain; charset=ISO-8859-1

Scott...

On Fri, Jul 16, 2010 at 5:48 PM, Scott Marlowe wrote:

>
> So what does
>
> sudo locate postgresql.conf
>
> say?
>

That I am irredeemably lazy as an admin? :)

/usr/share/pgsql/postgresql.conf.sample
/var/lib/pgsql/data/postgresql.conf
/home/archives/db/postgresql.conf
/home/postgres/data/postgresql.conf

The first line is the --datadir as reported by pg_configure --configure
The second line is the 7.4 data dir according to its PG_VERSION
The third line was a directory backup I made when I upgraded to 8.1
The fourth line is the most recently updated database according to the time
stamps. (three days ago)


Patric

--0016369f9d172b46ba048b8e5ea8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Scott...
>