On Fri, Mar 3, 2017 at 6:58 PM, Amit Kapila <amit.kapil...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
