Re: Count backend self-sync calls - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Count backend self-sync calls
Date
Msg-id AANLkTikGnJ=1H1B9=XsJ2VOnh4JqeA-6J07fKKL9Hbt0@mail.gmail.com
Whole thread Raw
In response to Re: Count backend self-sync calls  (Greg Smith <greg@2ndquadrant.com>)
Responses Re: Count backend self-sync calls
List 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 by date:

Previous
From: Greg Smith
Date:
Subject: Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+
Next
From: Robert Haas
Date:
Subject: Re: Count backend self-sync calls