On Tue, Apr 4, 2017 at 6:29 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Mon, Mar 27, 2017 at 7:04 PM, Ashutosh Sharma <ashu.coe...@gmail.com> > wrote: >> My guess (which could be wrong) is that so->hashso_bucket_buf = >>> InvalidBuffer should be moved back up higher in the function where it >>> was before, just after the first if statement, and that the new >>> condition so->hashso_bucket_buf == so->currPos.buf on the last >>> _hash_dropbuf() should be removed. If that's not right, then I think >>> I need somebody to explain why not. >> >> Okay, as i mentioned above, in case of page scan mode we only keep pin >> on a bucket buf. There won't be any case where we will be having pin >> on overflow buf at the end of scan. >> > > What if mark the buffer as invalid after releasing the pin? We are > already doing it that way in btree code, refer > _bt_drop_lock_and_maybe_pin(). I think if we do that way, then we can > do what Robert is suggesting.
Please continue reviewing, but I think we're out of time to get this patch into v10. This patch seems to be still under fairly heavy revision, and we're only a couple of days from feature freeze, and the patch upon which it depends (page-at-a-time vacuum) has had no fewer than four follow-up commits repairing various problems with the logic, with no guarantee that we've found all the bugs yet. In view of those facts, I don't think it would be wise for me to commit this to v10, so I'm instead going to move it to the next CommitFest. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
