Re: New FSM patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: New FSM patch
Date
Msg-id 24049.1221762893@sss.pgh.pa.us
Whole thread Raw
In response to Re: New FSM patch  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Responses Re: New FSM patch  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: FSM patch - performance test
Next
From: Heikki Linnakangas
Date:
Subject: Re: New FSM patch