At Wed, 22 Mar 2017 02:15:26 +0900, Masahiko Sawada <sawada.m...@gmail.com> wrote in <cad21aoaq2yhs3mvsky6txx1okqyipwuphdsa2sjcab_v4ci...@mail.gmail.com> > On Mon, Mar 20, 2017 at 11:28 PM, Robert Haas <robertmh...@gmail.com> wrote: > > On Sat, Mar 18, 2017 at 5:42 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > >> 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? > > > > Yes, updates to the FSM are never logged. Forcing replay of > > HEAP2_FREEZE_PAGE to update the FSM might be a good idea. > > > > I think I was missing something. I imaged your situation is that FPI > is replayed during crash recovery after the crashed server vacuums the > page and marked it as all-frozen. But this situation is also resolved > by that solution.
# HEAP2_CLEAN is issued in lazy_vacuum_page It will work but I'm not sure it is right direction for HEAP2_FREEZE_PAGE to touch FSM. As Masahiko said, the situation must be created by HEAP2_VISIBLE without preceding HEAP2_CLEAN, or with HEAP2_CLEAN with FPI. I think only the latter can happen. The comment in heap_xlog_clean below is right generally but if a page filled with tuples becomes almost empty and freezable by this cleanup, a problematic situation like this occurs. > /* > * Update the FSM as well. > * > * XXX: Don't do this if the page was restored from full page image. We > * don't bother to update the FSM in that case, it doesn't need to be > * totally accurate anyway. > */ > if (action == BLK_NEEDS_REDO) > XLogRecordPageWithFreeSpace(rnode, blkno, freespace); HEAP_INSERT/HEAP2_MULTI_INSERT/UPDATE does the similar. All of these reduces freespace but HEAP2_CLEAN increases. HEAP2_CLEAN occurs infrequently than the three. So I suppose HEAP2_CLEAN may always update FSM. Even if the page is not frozen, the similar situation is made with just ALL_VISIBLE. Without any updates on the page, freespace information for the page won't be corrected until the next freezing(or 'aggressive') vacuum occurs. >From this point of view, HEAP2_FREEZE_PAGE is not responsible for updating FSM. But if we see that always updating FSM on HEAP2_CLEAN is too much, HEAP2_FREEZE_PAGE would be the next way to go. (I don't understand the reason for skipping updating FSM only for FPI. This seems introduced by f8f42279) regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
