Re: Count backend self-sync calls

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Count backend self-sync calls
Дата
Msg-id AANLkTik+2f=BYdkUZdySbZrfZ4r1Va1QJHH92C77qR+j@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Count backend self-sync calls  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Sun, Nov 14, 2010 at 8:31 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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.

Committed with (I think) all the changes discussed, plus a catversion bump.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Aidan Van Dyk
Дата:
Сообщение: Re: unlogged tables
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Re: Rethinking hint bits WAS: Protecting against unexpected zero-pages: proposal