On Sat, Mar 4, 2017 at 8:55 AM, Peter Geoghegan <p...@bowt.ie> wrote: > 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. >
Are you talking pg_class.relfrozenxid of index or table? IIUC, for indexes it will be InvalidTransactionId and for tables, I think it will be updated with or without the patch. > While I can't see this explained anywhere, I'm > pretty sure that that's supposed to be impossible, which this patch > changes. > What makes you think that patch will allow pg_class.relfrozenxid to be advanced past opaque->btpo.xact which was previously not possible? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
