On Tue, Nov 18, 2014 at 12:33 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Nov 17, 2014 at 10:31 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> On 2014-11-17 10:21:04 -0500, Robert Haas wrote:
>>> Andres, where are we with this patch?
>>>
>>> 1. You're going to commit it, but haven't gotten around to it yet.
>>>
>>> 2. You're going to modify it some more and repost, but haven't gotten
>>> around to it yet.
>>>
>>> 3. You're willing to see it modified if somebody else does the work,
>>> but are out of time to spend on it yourself.
>>>
>>> 4. Something else?
>>
>> I'm working on it. Amit had found a hang on PPC that I couldn't
>> reproduce on x86. Since then I've reproduced it and I think yesterday I
>> found the problem. Unfortunately it always took a couple hours to
>> trigger...
>>
>> I've also made some, in my opinion, cleanups to the patch since
>> then. Those have the nice side effect of making the size of struct
>> LWLock smaller, but that wasn't actually the indended effect.
>>
>> I'll repost once I've verified the problem is fixed and I've updated all
>> commentary.
>>
>> The current problem is that I seem to have found a problem that's also
>> reproducible with master :(. After a couple of hours a
>> pgbench -h /tmp -p 5440 scale3000 -M prepared -P 5 -c 180 -j 60 -T 20000 -S
>> against a
>> -c max_connections=200 -c shared_buffers=4GB
>> cluster seems to hang on PPC. With all the backends waiting in buffer
>> mapping locks. I'm now making sure it's really master and not my patch
>> causing the problem - it's just not trivial with 180 processes involved.
>
> Ah, OK. Thanks for the update.
Ping? This patch is in a stale state for a couple of weeks and still
marked as waiting on author for this CF.
--
Michael