Problem has now been solved. Thanks a lot for all your help.
On 5/12/08, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> "James Farrugia" <[EMAIL PROTECTED]> writes:
> > One last thing...can we run into data-loss problems with successfully
> > vacuumed tables even if there is one unvacuumed database obje
"James Farrugia" <[EMAIL PROTECTED]> writes:
> 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 withi
Hi Tino,
That was what we suspected and in fact didn't want to run any unnecessary
risks. Thanks again.
James.
On 5/12/08, Tino Schwarze <[EMAIL PROTECTED]> wrote:
>
> Hi James,
>
> On Mon, May 12, 2008 at 09:25:34AM +0200, James Farrugia wrote:
>
> > First of all thanks for the immediate repl
Hi James,
On Mon, May 12, 2008 at 09:25:34AM +0200, James Farrugia wrote:
> 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 ca
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
"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-index
"James Farrugia" <[EMAIL PROTECTED]> writes:
> I wonder whether any of you can help me out with this problem.
What PG version is this?
> To get vacuum the TOAST object we created a temporary table foo (col1
> char(1)) and assigned its reltoastrelid (up till now set to 0) to
> pg_toast_35027430's
Hi all,
I wonder whether any of you can help me out with this problem. We were
performed a routine "lazy" VACUUM in order to reassign frozen XIDs and
prevent data-loss.
After the VACUUM completed successfully, the command "SELECT datname,
age(datfrozenxid) FROM pg_database" still showed an exces
