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

On Sat, Dec 19, 2015 at 3:19 PM, Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)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(dot)vondra(at)2ndquadrant(dot)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