Re: Count backend self-sync calls
| От | Robert Haas |
|---|---|
| Тема | Re: Count backend self-sync calls |
| Дата | |
| Msg-id | AANLkTikGnJ=1H1B9=XsJ2VOnh4JqeA-6J07fKKL9Hbt0@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Count backend self-sync calls (Greg Smith <greg@2ndquadrant.com>) |
| Ответы |
Re: Count backend self-sync calls
|
| Список | pgsql-hackers |
On Sun, Nov 14, 2010 at 7:19 PM, Greg Smith <greg@2ndquadrant.com> wrote: >> But if this is generating a lot of log data or adding a lot of >> overhead, then you have bigger problems anyway: >> >> + elog(DEBUG1, "Unable to forward fsync request, executing >> directly"); >> > > The argument against this log line even existing is that if the field is > added to pg_stat_bgwriter, that's probably how you want to monitor this data > anyway. I'll remove it if you really want it gone, but personally I think it's useful to have. I've more than once had to debug a problem given a PostgreSQL log file with the debug level cranked up and not a whole lot else. Rare events that cause performance to tank are worth logging, IMHO. > I started out touching code that called it just "sync", but then crossed to > other code that called it "fsync", and made the external UI use that name. > No objections to sorting that out within my patch so it's consistent. OK, I'll do that before I commit it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: