Re: measuring lwlock-related latency spikes

Simon Riggs <simon@2ndquadrant.com>

From: Simon Riggs <simon@2ndQuadrant.com>

To: Greg Stark <stark@mit.edu>

Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org

Date: 2012-03-31T14:21:48Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Add new files to NLS file lists
- 194b5ea3d072 9.2.0 cited

On Sat, Mar 31, 2012 at 1:58 PM, Greg Stark <stark@mit.edu> wrote:
> On Sat, Mar 31, 2012 at 4:41 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> But I didn't think we were ever supposed to hold content
>> locks for that long.
>
> Isn't that lock held while doing visibility checks? What about I/O
> waiting for a clog page to be read?

So what we should be logging is the list of lwlocks held when the lock
wait occurred.

That would differentiate call paths somewhat better than just looking
at the current lock request.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services