On 2013-02-04 11:07:17 -0500, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
