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
Re: GetOldestXmin going backwards is dangerous after all |
Список | 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 по дате отправления: