On Sun, Apr 1, 2012 at 11:12 PM, Greg Stark <st...@mit.edu> wrote: > On Sun, Apr 1, 2012 at 10:27 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >> So lock starvation on the control lock would cause a long wait after >> each I/O, making it look like an I/O problem. > > Except that both of the locks involved in his smoking gun occur > *after* the control lock has already been acquired. The one that's > actually being blocked for a long time is in fact acquiring a shared > lock which the queue jumping couldn't be hurting.
Not true, please refer to code at line 544, as I already indicated. My understanding of the instrumentation is that the lock acquired at line 526 will show as the blocker until we reach line 555, so anything in between could be responsible for the wait. (As long as there are multiple possibilities, I will remain convinced that the cause could be any of them.) -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
