Re: GetOldestXmin going backwards is dangerous after all

On 2013-02-04 11:07:17 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2013-02-01 19:24:02 -0500, Tom Lane wrote:
> >> And as for that, it's been pretty clear for awhile that allowing
> >> vacuum_defer_cleanup_age to change on the fly was a bad idea we'd
> >> eventually have to undo. The day of reckoning has arrived: it needs
> >> to be PGC_POSTMASTER.
>
> > ISTM that the original problem can still occur, even after Simon's
> > commit.
> > 1) start with -c vacuum_defer_cleanup_age=0
> > 2) autovacuum vacuums "test";
> > 3) restart with -c vacuum_defer_cleanup_age=10000
> > 4) autovacuum vacuums "test"'s toast table;
>
> > should result in about the same ERROR, shouldn't it?
>
> Hm ... yeah, you're right. So that's still not bulletproof.

ISTM that, unless we can guarantee that this won't cause GetOldestXmin
to backwards, there is no point in trying to make GetOldestXmin any
guarantees not to do so. Especially if that comes with a loss of
VACUUM's effectiveness.

I absolutely hate to suggest it, but what about storing the last
vacuum's xmin horizon in the main table's pg_class.options in the back
branches?
During heap_copy_data the assumed xmin horizon can be
Max(OldestXmin, main_table_last_vacuum_horizon, toast_table_last_vacuum_horizon)

That should solve the problem, right?

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services