Re: GetOldestXmin going backwards is dangerous after all

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: GetOldestXmin going backwards is dangerous after all
Дата
Msg-id 28103.1359994037@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: GetOldestXmin going backwards is dangerous after all  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: GetOldestXmin going backwards is dangerous after all  (Simon Riggs <simon@2ndQuadrant.com>)
Re: GetOldestXmin going backwards is dangerous after all  (Andres Freund <andres@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: sepgsql and materialized views
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: json api WIP patch