Re: pgsql 10: hash indexes testing
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, AP <ap@zip.com.au>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-08-05T02:20:06Z
Lists: pgsql-hackers
On Fri, Aug 4, 2017 at 2:45 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: > I have not done anything for this comment as it doesn't sound wrong to > me. I think it is not making much sense in the current code and we > can remove it or change it as part of the separate patch if you or > others think so. I don't get it. The comment claims we have to _hash_getnewbuf before releasing the metapage write lock. But the function neither calls _hash_getnewbuf nor releases the metapage write lock. It then goes on to say that for this reason we pass the new buffer rather than just the block number. However, even if it were true that we have to call _hash_getnewbuf before releasing the metapage write lock, what does that have to do with the choice of passing a buffer vs. a block number? Explain to me what I'm missing, please, because I'm completely befuddled! (On another note, I committed these patches.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
pgstatindex: Insert some casts to prevent overflow.
- 0b7ba3d6474b 10.0 cited
-
hash: Immediately after a bucket split, try to clean the old bucket.
- ff98a5e1e49d 10.0 landed
-
hash: Increase the number of possible overflow bitmaps by 8x.
- 620b49a16d2a 10.0 landed
-
BRIN auto-summarization
- 7526e10224f0 10.0 cited