On Thu, Nov 5, 2015 at 2:44 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > The bug theoretically exists in 9.5, but it wasn't until 9.6 (commit > e95680832854cf300e64c) that free pages were recycled aggressively > enough that it actually becomes likely to be hit.
In other words: The bug could be in 9.5, but that hasn't been conclusively demonstrated. Fair? I'm not an expert on GIN at all; I know far more about B-Tree. But, commit e95680832854cf300e64c seems a bit odd to me. I don't see any argument for why it's okay that the recycling of pages can happen immediately for the pending list, rather than requiring it to happen at some time later with a safe interlock (some like B-Tree's use of RecentGlobalXmin). The GIN README discusses a few such issues, but it wasn't updated by the commit I mentioned, which I would have expected. OTOH, after all of 10 minutes I can't see what's special about ginvacuumcleanup() that makes its long established RecordFreeIndexPage() call fundamentally safer, which if true would be a surprisingly obvious defect to go unfixed for all these years. This is what you yourself said about it, I think. I need to look at it again with fresh eyes, but offhand having no safe interlock for the well established RecordFreeIndexPage() call for GIN seems like an implausibly obvious bug. -- 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
