On Tue, Mar 13, 2018 at 4:57 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Mon, Mar 12, 2018 at 7:18 PM, Amit Kapila <amit.kapil...@gmail.com> > wrote: > > On Mon, Mar 12, 2018 at 12:18 AM, Alexander Korotkov > > <a.korot...@postgrespro.ru> wrote: > >> On Sat, Mar 3, 2018 at 2:53 PM, Amit Kapila <amit.kapil...@gmail.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
