On Mon, Nov 17, 2014 at 10:31 AM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
