Re: GetOldestXmin going backwards is dangerous after all

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: GetOldestXmin going backwards is dangerous after all
Date: 2013-02-04 16:43:41
Message-ID: 20130204164341.GB22226@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-02-04 16:52:05 Re: GetOldestXmin going backwards is dangerous after all
Previous Message Simon Riggs 2013-02-04 16:33:37 Re: GetOldestXmin going backwards is dangerous after all