Re: FSM corruption leading to errors

I wrote:
> It looks to me like this is approximating the highest block number that
> could possibly have an FSM entry as size of the FSM fork (in bytes)
> divided by 2.  But the FSM stores one byte per block.  There is overhead
> for the FSM search tree, but in a large relation it's not going to be as
> much as a factor of 2.  So I think that to be conservative we need to
> drop the "/ 2".  Am I missing something?

Ah, scratch that, after rereading the FSM README I see it's correct,
because there's a binary tree within each page; I'd only remembered
that there was a search tree of pages.

Also, we could at least discount the FSM root page and first intermediate
page, no?  That is, the upper limit could be
pg_relation_size(oid::regclass, 'fsm') / 2 - 2*current_setting('block_size')::BIGINT

I think this is a worthwhile improvement because it reduces the time spent
on small relations.  For me, the query as given takes 9 seconds to examine
the regression database, which seems like a lot.  Discounting two pages
reduces that to 20 ms.
        regards, tom lane