Re: GetOldestXmin going backwards is dangerous after all - Mailing list pgsql-hackers

From Tom Lane
Subject Re: GetOldestXmin going backwards is dangerous after all
Date
Msg-id 28103.1359994037@sss.pgh.pa.us
Whole thread Raw
In response to Re: GetOldestXmin going backwards is dangerous after all  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: GetOldestXmin going backwards is dangerous after all
Re: GetOldestXmin going backwards is dangerous after all
List pgsql-hackers
Andres Freund <andres@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.

> Given that there seemingly isn't yet a way to fix that people agree on
> and that it "only" result in a transient error I think the fix for this
> should be pushed after the next point release.

Agreed, we can let this go until we have a more complete solution.

Simon, would you revert the vacuum_defer_cleanup_age changes?
We should wait till we have a complete fix before forcing that
redefinition on users.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: sepgsql and materialized views
Next
From: Andrew Dunstan
Date:
Subject: Re: json api WIP patch