Re: Incomplete freezing when truncating a relation during vacuum

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Incomplete freezing when truncating a relation during vacuum
Дата
Msg-id 5295B503.3050202@vmware.com
обсуждение исходный текст
Ответ на Re: Incomplete freezing when truncating a relation during vacuum  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Incomplete freezing when truncating a relation during vacuum  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On 11/27/13 01:21, Andres Freund wrote:
> On 2013-11-26 13:32:44 +0100, Andres Freund wrote:
>> This seems to be the case since
>> b4b6923e03f4d29636a94f6f4cc2f5cf6298b8c8. I suggest we go back to using
>> scan_all to determine whether we can set new_frozen_xid. That's a slight
>> pessimization when we scan a relation fully without explicitly scanning
>> it in its entirety, but given this isn't the first bug around
>> scanned_pages/rel_pages I'd rather go that way. The aforementioned
>> commit wasn't primarily concerned with that.
>> Alternatively we could just compute new_frozen_xid et al before the
>> lazy_truncate_heap.
>
> I've gone for the latter in this preliminary patch. Not increasing
> relfrozenxid after an initial data load seems like a bit of a shame.
>
> I wonder if we should just do scan_all || vacrelstats->scanned_pages <
> vacrelstats->rel_pages?

Hmm, you did (scan_all || vacrelstats->scanned_pages <
vacrelstats->rel_pages) for relminmxid, and just
(vacrelstats->scanned_pages < vacrelstats->rel_pages) for relfrozenxid.
That was probably not what you meant to do, the thing you did for
relfrozenxid looks good to me.

Does the attached look correct to you?

- Heikki

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Platform-dependent(?) failure in timeout handling
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Platform-dependent(?) failure in timeout handling