Re: Cause of moving-target FSM space-needed reports

Tom Lane wrote:
> I think it's reasonable for vacuumlazy.c to track at most MaxFSMPages
> pages as it's doing now --- but it should keep a separate count of the
> total number of pages with at least threshold amount of free space, and
> pass that as a separate argument to RecordRelationFreeSpace.  This will
> not take any more space in shared memory than we already use, but it
> will allow us to report a truthful value for "number of pages needed",
> which we clearly are failing to do now.
>
> It might also be a good idea if vacuum verbose reported this page count,
> since when you've got a single table bloated like this, VACUUM FULL or
> CLUSTER might be a more appropriate solution than increasing the FSM
> size --- but there's no way to know which rel is the problem from the
> FSM total.  In fact, maybe vacuum should just throw a WARNING when it
> finds a single rel with more than MaxFSMPages pages with useful free space?
>
> Comments?  I'd like to put in a fix for beta1, which means today ...
>   


Sounds reasonable - it's arguably a bug, albeit relatively benign. I 
guess it might be less likely in 8.2 anyway given that we will have more 
generous default max_fsm_pages settings in most cases.

cheers

andrew