On 29.06.2018 15:48, Robert Haas wrote:
> On Wed, Jun 27, 2018 at 10:27 PM, Michael Paquier <[email protected]> wrote:
>> On Wed, Jun 27, 2018 at 07:32:18PM +0300, Konstantin Knizhnik wrote:
>>> I wonder why we are monitoring time of writing to WAL, but not time of
>>> fsyncing WAL segments?
>>> Is there are principle reason for it or just because nobody added it yet?
>>> If so, please find very small patch which adding WAIT_EVENT_WAL_FSYNC event
>>> type.
>> Let's name it WAIT_EVENT_WAL_SYNC as it is more consistent with the
>> other wait events of the same type, and also list the wait event
>> alphabetically everywhere this is added. I have also reworded the
>> documentation to be more consistent.
>>
>>> Our engineers in PgPro complain me that there is no information about time
>>> spent in syncing WALs...
>>> Unfortunately Postgres still is not able to aggregate this statistic. But at
>>> least we have pg_wait_sampling extension for it:
>>> https://github.com/postgrespro/pg_wait_sampling
>> Complain justified. It is a bit too late for v11 I think though, so
>> let's wait for v12 to open for business, and then I'll apply the patch
>> at if there are no objections until then.
> Are there other instances of fsync() that also need to be covered?
>
Syncing database files is already monitored (in mdsync and FileFlush).
If we grep for pg_fsync occurrences in Postgres code, then the only
place where pgstat_report_wait_start is not called before is
issue_xlog_fsync in xlog.c
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
