Re: Orphan TOAST object

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

Hi Tom,

First of all thanks for the immediate replies!
Was actually waiting for the right moment to upgrade to 8.3 but migrating
a
live 1Tb database is a bit daunting especially if you have never done it
before (as in my case).  If I'm not mistaken i can upgrade to the latest
minor version without having to dump and restore so I'll do that.

One last thing...can we run into data-loss problems with successfully
vacuumed tables even if there is one unvacuumed database object; what
would
have happened if I ignored to vacuum that rogue pg_toast (which was the
only
unvacuumed object within the entire database)?

Thanks again.

James

On 5/11/08, Tom Lane <tgl@[EMAIL PROTECTED]
> wrote:
>
> "James Farrugia" <james.farrugia@[EMAIL PROTECTED]
> writes:
> > I'm running 8.2.1.
>
> You really need to update to 8.2.latest.  There are several known
> data-corruption problems in 8.2.1, and it seems possible that one of
> them ate the pg_depend row you needed.
>
> > I cleanly forgot about pg_depend!
> > Even after re-indexing I wasn't able to find an entry in pg_depend
> having
> > the TOAST's OID.  I guess that by creating foo again and linking
> > pg_toast_xxx with foo in pg_depend by hand i can make it go away.
>
> Yeah, that's probably the cleanest recovery strategy.
>
>                        regards, tom lane
>

------=_Part_19_13322358.1210577134809
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div>Hi Tom,</div>
<div>&nbsp;</div>
<div>First of all thanks for the immediate replies!&nbsp; </div>
<div>Was actually waiting for the right moment to upgrade to 8.3 but
migrating a live 1Tb database is a bit daunting especially if you have
never done it before (as in my case).&nbsp; If I&#39;m not mistaken i can
upgrade to the latest minor version without having to dump and restore so
I&#39;ll do that.</div>

<div>&nbsp;</div>
<div>One last thing...can we run into data-loss problems&nbsp;with
successfully vacuumed tables even if there is one unvacuumed database
object; what would have happened if I ignored to vacuum that rogue
pg_toast (which was the only unvacuumed object within the entire
database)?&nbsp;</div>

<div>&nbsp;</div>
<div>Thanks again.<br><br>James</div>
<div>&nbsp;</div>
<div><span class="gmail_quote">On 5/11/08, <b class="gmail_sendername">Tom
Lane</b> &lt;<a href="mailto:tgl@[EMAIL PROTECTED]
">tgl@[EMAIL PROTECTED]
>&gt;
wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px
0px 0.8ex; BORDER-LEFT: #ccc 1px solid">&quot;James Farrugia&quot; &lt;<a
href="mailto:james.farrugia@[EMAIL PROTECTED]
">james.farrugia@[EMAIL PROTECTED]
>&gt;
writes:<br>
&gt; I&#39;m running <a href="http://8.2.1.">8.2.1.</a><br><br>You
really
need to update to 8.2.latest.&nbsp;&nbsp;There are several
known<br>data-corruption problems in 8.2.1, and it seems possible that one
of<br>them ate the pg_depend row you needed.<br>
<br>&gt; I cleanly forgot about pg_depend!<br>&gt; Even after re-indexing
I wasn&#39;t able to find an entry in pg_depend having<br>&gt; the
TOAST&#39;s OID.&nbsp;&nbsp;I guess that by creating foo again and
linking<br>&gt; pg_toast_xxx with foo in pg_depend by hand i can make it
go away.<br>
<br>Yeah, that&#39;s probably the cleanest recovery
strategy.<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
regards, tom lane<br></blockquote></div><br>

------=_Part_19_13322358.1210577134809--