From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Sami Imseih <samimseih(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: stats.sql fails during installcheck on mac |
Date: | 2025-04-11 04:26:10 |
Message-ID: | Z_iZ4k4E_xmnOokK@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 10, 2025 at 04:39:45PM -0500, Sami Imseih wrote:
> Also, The documentation for pg_stat_wal already makes this point clear
> in [0] that "wal_sync is only
> incremented when the wal_sync_method is either fdatasync, fsync or
> fsync_writethrough".
>
> Perhaps, the same clarification will be beneficial for the
> pg_stat_io.fsyncs* fields?
wal_sync and wal_sync_time (and the write parts) have been moved from
pg_stat_wal to pg_stat_io under the 'wal' object, and these details
with wal_sync_method are documented here:
https://www.postgresql.org/docs/devel/wal-configuration.html
The docs of pg_stat_io include a paragraph that link to the WAL
configuration:
https://www.postgresql.org/docs/devel/monitoring-stats.html#MONITORING-PG-STAT-IO-VIEW
`For the object wal, fsyncs and fsync_time track the fsync.. blah.`
The current format is intentional to reduce the amount of duplication
in the docs regarding this level of details to one place: the section
that describes in details the internals of the WAL I/O activity.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-04-11 04:51:08 | Re: merge file_exists_in_directory and _fileExistsInDirectory functions and move into common file dumputils.c |
Previous Message | Peter Smith | 2025-04-11 04:21:19 | Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding |