On Fri, Mar 3, 2017 at 6:58 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> You are right that we don't want the number of unclaimed-by-FSM
> recyclable pages to grow forever, but I think that won't happen with
> this patch. As soon as there are more deletions (in heap), in the
> next vacuum cycle, the pages will be reclaimed by lazy_vacuum_index().
Right.
>> (Thinks about it some more...)
>>
>> Unfortunately, I just saw a whole new problem with this patch:
>> _bt_page_recyclable() is the one place in the B-Tree AM where we stash
>> an XID.
>>
>
> Can you be more specific to tell which code exactly you are referring here?
I meant that we stash an XID when a B-Tree page is deleted, used to
determine when it's finally safe to to recycle the page by comparing
it to RecentGlobalXmin (recyling will happen during the next VACUUM).
We can't immediately recycle a page, because an existing index scan
might land on the page while following a stale pointer.
_bt_page_recyclable(), which checks if recycling is safe (no possible
index scan can land of dead page), is a pretty small function. I'm
concerned about what happens when
pg_class.relfrozenxid/pg_database.datfrozenxid are advanced past
opaque->btpo.xact. While I can't see this explained anywhere, I'm
pretty sure that that's supposed to be impossible, which this patch
changes.
--
Peter Geoghegan
