Re: Unexpected VACUUM FULL failure

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Unexpected VACUUM FULL failure
Дата
Msg-id 46BC7981.6040008@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Unexpected VACUUM FULL failure  (Gregory Stark <stark@enterprisedb.com>)
Ответы Re: Unexpected VACUUM FULL failure  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Gregory Stark wrote:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
> 
>> "Simon Riggs" <simon@2ndquadrant.com> writes:
>>
>>> ISTM that if we call HeapTupleSatisfiesVacuum() with an additional
>>> boolean parameter, force, we can tell VF to always set the hint bits in
>>> every case, not just HEAP_MOVED_IN and HEAP_MOVED_OUT.
>> Surely this approach is no good: won't it allow hint bits to reach disk
>> in advance of their transaction?
> 
> I don't think so since it sounds like he's saying to still sync the log and
> VACUUM FULL has an exclusive lock on the table. So any committed (or aborted)
> changes it sees in the table must have been committed or aborted before the
> log sync.

Hint bit updates are not WAL-logged, so there's no mechanism to keep the
data page from hitting the disk before the COMMIT record. That's the
reason why we can't just set the hint bits for async committed
transactions in the first place.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com


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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: default_text_search_config and expression indexes
Следующее
От: Decibel!
Дата:
Сообщение: Re: pgcheck - data integrity check