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

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: [HACKERS] GSoC 2017: weekly progress reports (week 4) and patchfor hash index
Дата
Msg-id CAPpHfdvmTRgaSB1oZKe46s0eOUTwB+JPmX96t4FuDbLxBOeOUQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] GSoC 2017: weekly progress reports (week 4) and patchfor hash index  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: [HACKERS] GSoC 2017: weekly progress reports (week 4) and patchfor hash index  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
Дерево обсуждения
On Sat, Mar 3, 2018 at 2:53 PM, Amit Kapila <amit.kapila16@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?

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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: [HACKERS] GSoC 2017: weekly progress reports (week 4) and patchfor hash index
Следующее
От: Pavel Stehule
Дата:
Сообщение: Using JIT for VACUUM, COPY, ANALYZE