Re: [HACKERS] GSoC 2017: weekly progress reports (week 4) and patch for hash index

On Tue, Mar 13, 2018 at 4:57 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:

> On Mon, Mar 12, 2018 at 7:18 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
> wrote:
> > On Mon, Mar 12, 2018 at 12:18 AM, Alexander Korotkov
> > <a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> >> On Sat, Mar 3, 2018 at 2:53 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
> wrote:
> >>>
> >>> On Fri, Mar 2, 2018 at 9:27 AM, Thomas Munro
> >>> > If that is indeed a race, could it be fixed by
> >>> > calling PredicateLockPageSplit() at the start of _hash_splitbucket()
> >>> > instead?
> >>> >
> >>>
> >>> Yes, but I think it would be better if we call this once we are sure
> >>> that at least one tuple from the old bucket has been transferred
> >>> (consider if all tuples in the old bucket are dead).
> >>
> >>
> >> Is it really fair? For example, predicate lock can be held by session
> >> which queried some key, but didn't find any corresponding tuple.
> >> If we imagine this key should be in new bucket while all existing
> >> tuples would be left in old bucket. As I get, in this case no locks
> >> would be transferred since no tuples were moved to the new bucket.
> >> So, further insertion to the new bucket wouldn't conflict with session,
> >> which looked for non-existing key, while it should. Do it make sense?
> >>
> >
> > Valid point, I think on split we should always transfer locks from old
> > bucket to new bucket.
> >
>
> Attached patch changes it as per above suggestion.

OK. Now patch looks good for me.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company