Re: [HACKERS] GUC for cleanup indexes threshold. - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: [HACKERS] GUC for cleanup indexes threshold.
Date
Msg-id 20170925.203759.207210095.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: [HACKERS] GUC for cleanup indexes threshold.  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
At Mon, 25 Sep 2017 19:20:07 +0900, Masahiko Sawada <sawada.mshk@gmail.com> wrote in
<CAD21AoAzKJnc8UM728c0BMHx=7itJh4Db_Lj3Y31itnGrj-heQ@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

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] logical replication and statistics
Next
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Shaky coding for vacuuming partitioned relations