Re: GIN data corruption bug(s) in 9.6devel

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: GIN data corruption bug(s) in 9.6devel
Дата
Msg-id CAMkU=1zXJ4v-zJ2q4_yBmSXgPnDQa68fj9My16iUe0cbygSiyg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: GIN data corruption bug(s) in 9.6devel  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: GIN data corruption bug(s) in 9.6devel  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
On Sat, Dec 19, 2015 at 3:19 PM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> Hi,
>
> On 11/06/2015 02:09 AM, Tomas Vondra wrote:
>>
>> Hi,
>>
>> On 11/06/2015 01:05 AM, Jeff Janes wrote:
>>>
>>> On Thu, Nov 5, 2015 at 3:50 PM, Tomas Vondra
>>> <tomas.vondra@2ndquadrant.com> wrote:
>>
>> ...
>>>>
>>>>
>>>> I can do that - I see there are three patches in the two threads:
>>>>
>>>>    1) gin_pending_lwlock.patch (Jeff Janes)
>>>>    2) gin_pending_pagelock.patch (Jeff Janes)
>>>>    3) gin_alone_cleanup-2.patch (Teodor Sigaev)
>>>>
>>>> Should I test all of them? Or is (1) obsoleted by (2) for example?
>>>
>>>
>>> 1 is obsolete.  Either 2 or 3 should fix the bug, provided this is the
>>> bug you are seeing.  They have different performance side effects, but
>>> as far as fixing the bug they should be equivalent.
>>
>>
>> OK, I'll do testing with those two patches then, and I'll also note the
>> performance difference (the data load was very stable). Of course, it's
>> just one particular workload.
>>
>> I'll post an update after the weekend.
>
>
> I've finally managed to test the two patches. Sorry for the delay.
>
> I've repeated the workload on 9.5, 9.6 and 9.6 with (1) or (2), looking for
> lockups or data corruption. I've also measured duration of the script, to
> see what's the impact on performance. The configuration (shared_buffers,
> work_mem ...) was exactly the same in all cases.
>
> 9.5     : runtime ~1380 seconds
> 9.6     : runtime ~1380 seconds (but lockups and data corruption)
> 9.6+(1) : runtime ~1380 seconds
> 9.6+(2) : runtime ~1290 seconds
>
> So both patches seem to do the trick, but (2) is faster. Not sure if this is
> expected. (BTW all the results are without asserts enabled).

Do you know what the size of the pending list was at the end of each test?

I think last one may be faster because it left a large mess behind
that someone needs to clean up later.

Also, do you have the final size of the indexes in each case?

Cheers,

Jeff



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Patch: Implement failover on libpq connect level.
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates