On Tue, Jan 24, 2017 at 3:10 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > 1. > @@ -505,26 +505,22 @@ hashbulkdelete(IndexVacuumInfo *info,
> In the above flow, do we really need an updated metapage, can't we use > the cached one? We are already taking care of bucket split down in > that function. Yes, we can use the old cached metap entry, the only reason I decided to use the latest metapage content is because the old code used to do that. And, cached metap is used to avoid ad-hoc local saving of same and hence unify the cached metap API. I did not intend to save the metapage read here which I thought will not be much useful if new buckets are added anyway we need to read the metapage at the end. I have taken you comments now I only read metap cache which is already set. > 2. > The above two chunks of code look worse as compare to your previous > patch. I think what we can do is keep the patch ready with both the > versions of _hash_getcachedmetap API (as you have in _v11 and _v12) > and let committer take the final call. _v11 API's was self-sustained one but it does not hold pins on the metapage buffer. Whereas in _v12 we hold the pin for two consecutive reads of metapage. I have taken your advice and producing 2 different patches. -- Thanks and Regards Mithun C Y EnterpriseDB: http://www.enterprisedb.com
cache_hash_index_meta_page_13_donotholdpin.patch
Description: Binary data
cache_hash_index_meta_page_13_holdpin.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers