Re: measuring lwlock-related latency spikes
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Simon Riggs <simon@2ndquadrant.com>, Greg Stark <stark@mit.edu>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2012-04-02T21:25:46Z
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 Apr 2, 2012, at 3:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Seems like basically what you've proven is that this code path *is* a > performance issue, and that we need to think a bit harder about how to > avoid doing the fsync while holding locks. Hmm, good idea. I wonder if we couldn't just hand off the fsync request to the background writer, as we do with buffer fsync requests. AFAICS we don't need the fsync to happen right away; the next checkpoint cycle should be soon enough. ...Robert