Hi! Thanks, Alexander! > 8 дек. 2018 г., в 6:54, Alexander Korotkov <aekorot...@gmail.com> написал(а): > > Yep, please find attached draft patch.
Patch seems good to me, I'll check it in more detail. The patch gets posting item at FirstOffsetNumber instead of btree->getLeftMostChild(). This seem OK, since dataGetLeftMostPage() is doing just the same, but with few Assert()s. > BTW, it seems that I've another bug in GIN. README says that > > "However, posting trees are only > fully searched from left to right, starting from the leftmost leaf. (The > tree-structure is only needed by insertions, to quickly find the correct > insert location). So as long as we don't delete the leftmost page on each > level, a search can never follow a downlink to page that's about to be > deleted." > > But that's not really true once we teach GIN to skip parts of posting > trees in PostgreSQL 9.4. So, there might be a risk to visit page to > be deleted using downlink. But in order to get real problem, vacuum > should past cleanup stage and someone else should reuse this page, > before we traverse downlink. Thus, the risk of real problem is very > low. But it still should be addressed. There's a patch above in this thread 0001-Use-correct-locking-protocol-during-GIN-posting-tree.patch where I propose stamping every deleted page with GinPageSetDeleteXid(page, ReadNewTransactionId()); and avoid reusing the page before TransactionIdPrecedes(GinPageGetDeleteXid(page), RecentGlobalDataXmin). Should we leave alone this bug for future fixes to keep current fix noninvasive? Best regards, Andrey Borodin.
