From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | sawada(dot)mshk(at)gmail(dot)com |
Cc: | robertmhaas(at)gmail(dot)com, jeff(dot)janes(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: free space map and visibility map |
Date: | 2017-03-24 02:01:28 |
Message-ID: | 20170324.110128.33861889.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Wed, 22 Mar 2017 02:15:26 +0900, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote in <CAD21AoAq2YHs3MvSky6TxX1oKqyiPwUphdSa2sJCab_V4ci4VQ(at)mail(dot)gmail(dot)com>
> On Mon, Mar 20, 2017 at 11:28 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > On Sat, Mar 18, 2017 at 5:42 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tsunakawa, Takayuki | 2017-03-24 02:54:51 | Re: Do we create a new roadmap page for development? |
Previous Message | Andres Freund | 2017-03-24 02:00:03 | Re: WIP: Faster Expression Processing v4 |