From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: free space map and visibility map |
Date: | 2017-03-18 21:09:42 |
Message-ID: | CAD21AoBdowp-FMMLJYz+9Xey2PhEs5R_4YC0VyfZvgo22+49RA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
>
> 'VACUUM (DISABLE_PAGE_SKIPPING) foo;' does fix it, but that seems to be
> the only thing that will.
If the above is correct, another one option is to allow
heap_xlog_clean to update fsm even when appling FPI.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2017-03-18 21:42:09 | Re: free space map and visibility map |
Previous Message | Tom Lane | 2017-03-18 20:23:17 | Re: Removing binaries (was: createlang/droplang deprecated) |