Zdenek Kotala <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
