From: Achilleas Mantzios <achill@matrix.gatewaynet.com>
Organization: Dynacom Tankers Mgmt
To: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>, pgsql-admin@postgresql.org
Subject: Re: FK disappeared in 8.3.3
Date: Tue, 23 Nov 2010 11:39:27 +0300
User-Agent: KMail/1.9.7
References: <201011221213.32035.achill@matrix.gatewaynet.com>
	<201011221757.18325.achill@matrix.gatewaynet.com>
	<4CEA49C80200002500037CF4@gw.wicourts.gov>
In-Reply-To: <4CEA49C80200002500037CF4@gw.wicourts.gov>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <201011231039.27966.achill@matrix.gatewaynet.com>

=CE=A3=CF=84=CE=B9=CF=82 Monday 22 November 2010 18:45:28 =CE=B3=CF=81=CE=
=AC=CF=88=CE=B1=CF=84=CE=B5:
> Achilleas Mantzios <achill@matrix.gatewaynet.com> wrote:
> =20
> > (imagine having to upgrade 61 installations for which you dont
> > have ssh/scp ;) sounds fun right? )
> =20
> I don't have to imagine -- been there, done that.  (Not with ships
> but large geographical distances and needing to trudge through
> secure facilities with big steel doors every so many feet.)  It can
> be time-consuming and tedious.  But then, so can recovering a
> corrupted database.

What you describe is an entirely different situation.

> =20
> If I were in your shoes, I'd consider arranging to have a CD-ROM
> mailed to someone on each ship at its next port, with a script which
> would automatically perform the update.  (Heavily tested in advance,
> of course.)

This in unrealistic. Many things can go wrong, and in this case the vessel
stays offline, which is a very very bad thing.
(imagine to be hard to make a telephone call, and after hours of effort to =
hear a nice Indian
guy with whom you cant communicate due to different accents of English
since both we are non native english speakers)
btw, we use tsearch2, intarray, which require an upgrade plan by their own,
if you have ever done this.
In addition, i must say that we have about 290 tables in our schema.
Its not the kind of DB you would simply upgrade with a CDROM.
The huge improvements between 7.4.* and 8.3.* were about performance
and not stability. Lack of stability is not smth PostgreSQL is famous for.
So we perform the upgrade to 8.3 only when we send one of our people
onboard.

> =20
> Of course, none of that helps with your current issue; I would just
> hate to see you pop up here in a few months with bigger problems
> than this if it can be avoided.
> =20

We had bigger problems than this and still survived, dont worry ;)
PostgreSQL (be it 7.4.2, 7.4.19 or 8.3.3) in our 60+ vessels, is the last t=
hing we have worried about
over the last 10 years. Generally PostgreSQL lasts even after hardware/OS h=
ave given up.

Dont get me wrong, i would love to see all our systems running the latest 9=
=2E0.1, and all the rest of software
(jboss, java, linux) to be on their latest releases.
However this is such a huge project to accomplish and our human resources a=
re very limited.
(i am the DBA, linux, freebsd sysadm, java j2ee programmer, architect, etc.=
=2E...)

Also, if there is no explicit upgrade plan (first in the office, second on =
vessels), then i prefer sticking=20
to 8.3.3 on the vessels, until we commit to do a serious upgrade.
I cannot start an initiative by myself, only to find later, that i just inc=
reased my own time spend on managing
who has what in the whole fleet.

But the real pain is the lack of TCP/IP and remote shell whenever we want i=
t.

Anyways thanx for helping by sharing your thoughts.

> -Kevin
>=20


=2D-=20
Achilleas Mantzios