Re: [HACKERS] Write Ahead Logging for Hash Indexes

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: [HACKERS] Write Ahead Logging for Hash Indexes
Дата
Msg-id CAA4eK1KDdJP5aAetbS4QULMkWA1f1oNQGp0m-RCAxz-hPBDihw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Write Ahead Logging for Hash Indexes  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
On Sat, Feb 4, 2017 at 4:37 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Thu, Jan 12, 2017 at 7:23 PM, Amit Kapila <amit.kapila16@gmail.com>
> wrote:
>>
>> On Fri, Jan 13, 2017 at 1:04 AM, Jesper Pedersen
>> <jesper.pedersen@redhat.com> wrote:
>> > On 12/27/2016 01:58 AM, Amit Kapila wrote:
>> >>
>> >> After recent commit's 7819ba1e and 25216c98, this patch requires a
>> >> rebase.  Attached is the rebased patch.
>> >>
>> >
>> > This needs a rebase after commit e898437.
>> >
>>
>> Attached find the rebased patch.
>>
>> Thanks!
>
>
> I've put this through a lot of crash-recovery testing using different
> variations of my previously posted testing harness, and have not had any
> problems.
>

Thanks for detailed testing of this patch.

> I occasionally get deadlocks which are properly detected.  I think this is
> just a user-space problem, not a bug, but will describe it anyway just in
> case...
>
> What happens is that connections occasionally create 10,000 nuisance tuples
> all using the same randomly chosen negative integer index value (the one the
> hash index is on), and then some time later delete those tuples using the
> memorized negative index value, to force the page split and squeeze to get
> exercised.  If two connections happen to choose the same negative index for
> their nuisance tuples, and then try to delete "their" tuples at the same
> time, and they are deleting the same 20,000 "nuisance" tuples concurrently
> with a bucket split/squeeze/something, they might see the tuples in a
> different order from each other and so deadlock against each other waiting
> on each others transaction locks due to "locked" tuples.  Is that a
> plausible explanation?
>

Yes, that is right explanation for the deadlock you are seeing.  A few
days back Jesper and Ashutosh Sharma have also faced the same problem
[1] with the similar test (non-unique values in hash index).  To
explain in brief, how this can happen is that squeeze operation moves
tuples from the far end of the bucket to rear end and it is quite
possible that different backends can see tuples with same values in a
different order.


[1] - https://www.postgresql.org/message-id/CAE9k0PmBGrNO_s%2ByKn72VO--ypaXWemOsizsWr5cHjEv0X4ERg%40mail.gmail.com

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



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

Предыдущее
От: Ashutosh Sharma
Дата:
Сообщение: Re: [HACKERS] [COMMITTERS] pgsql: pageinspect: Try to fix some bugs in previous commit.
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] Packages: Again