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).
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services