On Sat, Mar 18, 2017 at 2:09 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote:
> On Fri, Mar 17, 2017 at 9:37 PM, Jeff Janes <jeff.ja...@gmail.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
