On Mon, Jan 17, 2011 at 6:07 PM, Jim Nasby <j...@nasby.net> wrote: > On Jan 15, 2011, at 8:15 AM, Robert Haas wrote: >> Well, the point of this is not to save time in the bgwriter - I'm not >> surprised to hear that wasn't noticeable. The point is that when the >> fsync request queue fills up, backends start performing an fsync *for >> every block they write*, and that's about as bad for performance as >> it's possible to be. So it's worth going to a little bit of trouble >> to try to make sure it doesn't happen. It didn't happen *terribly* >> frequently before, but it does seem to be common enough to worry about >> - e.g. on one occasion, I was able to reproduce it just by running >> pgbench -i -s 25 or something like that on a laptop. > > Wow, that's the kind of thing that would be incredibly difficult to figure > out, especially while your production system is in flames... Can we change > ereport that happens in that case from DEBUG1 to WARNING? Or provide some > other means to track it?
Something like this? http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=3134d8863e8473e3ed791e27d484f9e548220411 -- 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
