At Mon, 25 Sep 2017 19:20:07 +0900, Masahiko Sawada <sawada.m...@gmail.com> wrote in <CAD21AoAzKJnc8UM728c0BMHx=7itjh4db_lj3y31itngrj-...@mail.gmail.com> > >> * we stash an XID when a btree page is deleted, which is used to > >> determine when it's finally safe to recycle the page > > > > Is it a "problem" of this proposal? > > > > As Peter explained before[1], the problem is that there is an XID > stored in dead btree pages that is used in the subsequent > RecentGlobalXmin interlock that determines if recycling is safe. > > [1] > https://www.postgresql.org/message-id/CAH2-Wz%3D1%3Dt5fcGGfarQGcAWBqaCh%2BdLMjpYCYHpEyzK8Qg6OrQ%40mail.gmail.com
Yeah I know that, and I understand that it is the reason why it is bad to just skip looking the GUC regardless. On the other hand looking the recycle status, I think we don't need the GUC. (I believe) The patch is *a Poc* in the way. (I'd like to let RecordPageWithFreeSpace to return the previous value to avoid duplicate fsm search..) 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
