Re: relfrozenxid not getting reset even after manual VACUUM - Mailing list pgsql-admin

From Armand du Plessis
Subject Re: relfrozenxid not getting reset even after manual VACUUM
Date
Msg-id CANf99sURnvMe=pL7nROZ4+_tYVgs7hPAbamcVp7W4zkCxDxh3g@mail.gmail.com
Whole thread Raw
In response to Re: relfrozenxid not getting reset even after manual VACUUM  (Albe Laurenz <laurenz.albe@wien.gv.at>)
List pgsql-admin
Thanks a lot Albe, Gezeala. 

I missed the 701995 dead rows cannot be removed yet in the logs (was late) and will now know to check the toast tables as well if this happens again. 

Thank you!

Armand


On Tue, Aug 6, 2013 at 9:04 AM, Albe Laurenz <laurenz.albe@wien.gv.at> wrote:
Armand du Plessis wrote:
> We're running into a scenario where despite doing a manual vacuum as a superuser the relfrozenxid for
> one relation now dangerously close to wraparound is not getting reset.
>
> It's a Postgres 9.2.3 cluster. We shutdown other access to the machine while running the VACUUM to
> ensure it could complete quick enough with an aggressive vacuum (vacuum_cost_limit 10000 and no
> delay). The previous autovacuum was running for days without completing.
>
> There's also no old transactions in either pg_prepared_xacts or pg_stat_activity.

> The tail-end of the vacuum log:
[...]
> DETAIL:  701995 dead row versions cannot be removed yet.

That's your problem.  Somebody must have been using these rows, unless
there is a bug.  That's an awfully high number too.

Yours,
Laurenz Albe

pgsql-admin by date:

Previous
From: Albe Laurenz
Date:
Subject: Re: After upgrading from 9.1.1 to 9.1.9, pgadmin's server status window gives error
Next
From: Brian Wong
Date:
Subject: Re: After upgrading from 9.1.1 to 9.1.9, pgadmin's server status window gives error