Received: from localhost (unknown [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id 4655664FC31
	for <pgsql-admin-postgresql.org@postgresql.org>;
	Wed, 24 Sep 2008 18:46:55 -0300 (ADT)
Received: from postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 17702-07 for <pgsql-admin-postgresql.org@postgresql.org>;
	Wed, 24 Sep 2008 18:46:52 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.239])
	by postgresql.org (Postfix) with ESMTP id 4387764FC2A
	for <pgsql-admin@postgresql.org>; Wed, 24 Sep 2008 18:46:52 -0300 (ADT)
Received: by qb-out-0506.google.com with SMTP id d8so97743qbc.23
	for <pgsql-admin@postgresql.org>; Wed, 24 Sep 2008 14:46:50 -0700 (PDT)
Received: by 10.187.158.2 with SMTP id k2mr2052766fao.15.1222292810003;
	Wed, 24 Sep 2008 14:46:50 -0700 (PDT)
Received: by 10.187.198.18 with HTTP; Wed, 24 Sep 2008 14:46:49 -0700 (PDT)
Message-ID: <3d78fcfd0809241446j326110c4p9907e04dbd10106b@mail.gmail.com>
Date: Wed, 24 Sep 2008 15:46:49 -0600
From: "BJ Taylor" <btaylor@propertysolutions.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Subject: Re: missing chunk number 0 for toast value
Cc: pgsql-admin@postgresql.org
In-Reply-To: <10862.1222287999@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_60883_23070458.1222292809990"
References: <3d78fcfd0809241132y14a832cai8b32bc32e936699e@mail.gmail.com>
	<10862.1222287999@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.001 tagged_above=0 required=5
	tests=HTML_MESSAGE=0.001
X-Spam-Level: 
X-Archive-Number: 200809/299
X-Sequence-Number: 30392

------=_Part_60883_23070458.1222292809990
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

We are using version 8.3.1.  And to be precise, when I started the vacuum
(analyze), I started it as a cron job to run daily around midnight.  The
next day I came in and checked on it and it was still running.  Not thinking
that it would take more than a full 24 hours to run, I let it be, and the
next day I came in and the server started acting weird.  I believe the
vacuum process continued to run, and a second vacuum process was started.
The server became unstable, and refused incoming connections.  At which
point, I killed all vacuum processes, and restarted postgresql.  I believe
it was somewhere during this process that the database became corrupted.  I
am not certain what happens when two vacuum processes run at the same time.
That may have been the problem, or it may not have.  Or it may have been
that I killed the vacuum process in the middle of what it was doing.  One
way or another, the problem that we have now, is that we are unable to get a
dump of the database for backups, and the database seems less stable than it
was previously (dropping connections, and refusing connections seemingly at
random).

BJ

On Wed, Sep 24, 2008 at 2:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> "BJ Taylor" <btaylor@propertysolutions.com> writes:
> > Our database seems to have been corrupted.  It is a heavily used
> database,
> > and went several months without any type of vacuuming.  When we finally
> > realized that it wasn't being vacuumed, we started the process, but the
> > process never successfully completed, and our database has never been the
> > same since.
>
> What PG version is this?  Exactly what do you mean by "never
> successfully completed"?
>
>                        regards, tom lane
>

------=_Part_60883_23070458.1222292809990
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div dir=3D"ltr">We are using version <a href=3D"http://8.3.1.">8.3.1.</a>&=
nbsp; And to be precise, when I started the vacuum (analyze), I started it =
as a cron job to run daily around midnight.&nbsp; The next day I came in an=
d checked on it and it was still running.&nbsp; Not thinking that it would =
take more than a full 24 hours to run, I let it be, and the next day I came=
 in and the server started acting weird.&nbsp; I believe the vacuum process=
 continued to run, and a second vacuum process was started.&nbsp; The serve=
r became unstable, and refused incoming connections.&nbsp; At which point, =
I killed all vacuum processes, and restarted postgresql.&nbsp; I believe it=
 was somewhere during this process that the database became corrupted.&nbsp=
; I am not certain what happens when two vacuum processes run at the same t=
ime.&nbsp; That may have been the problem, or it may not have.&nbsp; Or it =
may have been that I killed the vacuum process in the middle of what it was=
 doing.&nbsp; One way or another, the problem that we have now, is that we =
are unable to get a dump of the database for backups, and the database seem=
s less stable than it was previously (dropping connections, and refusing co=
nnections seemingly at random).&nbsp; <br>
<br>BJ<br><br><div class=3D"gmail_quote">On Wed, Sep 24, 2008 at 2:26 PM, T=
om Lane <span dir=3D"ltr">&lt;<a href=3D"mailto:tgl@sss.pgh.pa.us">tgl@sss.=
pgh.pa.us</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; p=
adding-left: 1ex;">
<div class=3D"Ih2E3d">&quot;BJ Taylor&quot; &lt;<a href=3D"mailto:btaylor@p=
ropertysolutions.com">btaylor@propertysolutions.com</a>&gt; writes:<br>
&gt; Our database seems to have been corrupted. &nbsp;It is a heavily used =
database,<br>
&gt; and went several months without any type of vacuuming. &nbsp;When we f=
inally<br>
&gt; realized that it wasn&#39;t being vacuumed, we started the process, bu=
t the<br>
&gt; process never successfully completed, and our database has never been =
the<br>
&gt; same since.<br>
<br>
</div>What PG version is this? &nbsp;Exactly what do you mean by &quot;neve=
r<br>
successfully completed&quot;?<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp;regards, tom lane<br>
</blockquote></div><br><br clear=3D"all"><br>
</div>

------=_Part_60883_23070458.1222292809990--