On Mon, Nov 17, 2014 at 10:31 AM, Andres Freund <andres@2ndquadrant.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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company