Re: free space map and visibility map

On Sat, Mar 18, 2017 at 2:09 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
wrote:

> On Fri, Mar 17, 2017 at 9:37 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> > With some intensive crash-recovery testing, I've run into a situation
> where
> > I get some bad table bloat. There will be large swaths of the table
> which
> > are empty (all results from heap_page_items other than lp are either
> zero or
> > NULL), but have zero available space in the fsm, and are marked as
> > all-visible and all-frozen in the vm.
> >
> > I guess it is a result of a crash causing updates to the fsm to be lost.
> > Then due to the (crash-recovered) visibility map showing them as all
> visible
> > and all frozen, vacuum never touches the pages again, so the fsm never
> gets
> > corrected.
>
> I guess that this happens only if heap_xlog_clean applies FPI. Right?
> Updating fsm can be lost but fsm is updated by replaying HEAP2_CLEAN
> record during crash recovery.
>

Isn't HEAP2_CLEAN only issued before an intended HOT update? (Which then
can't leave the block as all visible or all frozen). I think the issue is
here is HEAP2_VISIBLE or HEAP2_FREEZE_PAGE. Am I reading this correctly,
that neither of those ever update the FSM, regardless of FPI?

I don't know how to test the issue of which record is most responsible. I
could turn off FPW globally and see what happens, with some tweaking to my
testing harness.

Cheers,

Jeff