Re: New FSM patch

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: New FSM patch
Дата
Msg-id 24049.1221762893@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: New FSM patch  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Ответы Re: New FSM patch
Список pgsql-hackers
Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>>> 1) remove WAL logging. I think that FSM record should be recovered 
>>> during processing of others WAL records (like insert, update). 

Why are we WAL-logging FSM operations at all?  It's only a hint.

>> I think we'd still need to WAL log operations that decrease the amount 
>> of free space on page. Otherwise, after we have partial vacuum, we might 
>> never revisit a page, and update the FSM, even though there's usable 
>> space on the page, leaving the space forgotten forever.

Well, it'd be recovered eventually since sooner or later we'd have to
visit the page for tuple freezing purposes.  I'm not that worried about
losing space on individual pages anyway.  A more serious issue would be
if corruption of an upper-level FSM page caused a large swath of the
table to be effectively "forgotten", because the upper page had too
small a value in its entry.  But wouldn't this be more or less
self-repairing?  Assuming that the underlying table is active (if it
isn't you probably haven't got free space in it anyway) then once VACUUM
records free space on any page in the lost range, that would bubble up.

I think we could give serious consideration to not WAL-logging FSM,
with maybe a tweak here or there to improve the odds of self-repair.
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: FSM patch - performance test
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: New FSM patch