public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v56 4/6] Doc part of shared-memory based stats collector.
13+ messages / 6 participants
[nested] [flat]
* [PATCH v56 4/6] Doc part of shared-memory based stats collector.
@ 2020-03-19 06:11 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 13+ messages in thread
From: Kyotaro Horiguchi @ 2020-03-19 06:11 UTC (permalink / raw)
---
doc/src/sgml/catalogs.sgml | 6 +-
doc/src/sgml/config.sgml | 25 +++---
doc/src/sgml/high-availability.sgml | 13 +--
doc/src/sgml/monitoring.sgml | 127 +++++++++++++---------------
doc/src/sgml/ref/pg_dump.sgml | 9 +-
src/backend/postmaster/postmaster.c | 2 -
6 files changed, 85 insertions(+), 97 deletions(-)
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index b1de6d0674..0ef684d4d0 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -9261,9 +9261,9 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l
<para>
<xref linkend="view-table"/> lists the system views described here.
More detailed documentation of each view follows below.
- There are some additional views that provide access to the results of
- the statistics collector; they are described in <xref
- linkend="monitoring-stats-views-table"/>.
+ There are some additional views that provide access to the activity
+ statistics; they are described in
+ <xref linkend="monitoring-stats-views-table"/>.
</para>
<para>
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index a218d78bef..53d7dfda93 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -7375,11 +7375,11 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
<title>Run-time Statistics</title>
<sect2 id="runtime-config-statistics-collector">
- <title>Query and Index Statistics Collector</title>
+ <title>Query and Index Activity Statistics</title>
<para>
- These parameters control server-wide statistics collection features.
- When statistics collection is enabled, the data that is produced can be
+ These parameters control server-wide activity statistics features.
+ When activity statistics is enabled, the data that is produced can be
accessed via the <structname>pg_stat</structname> and
<structname>pg_statio</structname> family of system views.
Refer to <xref linkend="monitoring"/> for more information.
@@ -7395,14 +7395,13 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
</term>
<listitem>
<para>
- Enables the collection of information on the currently
- executing command of each session, along with the time when
- that command began execution. This parameter is on by
- default. Note that even when enabled, this information is not
- visible to all users, only to superusers and the user owning
- the session being reported on, so it should not represent a
- security risk.
- Only superusers can change this setting.
+ Enables activity tracking on the currently executing command of
+ each session, along with the time when that command began
+ execution. This parameter is on by default. Note that even when
+ enabled, this information is not visible to all users, only to
+ superusers and the user owning the session being reported on, so it
+ should not represent a security risk. Only superusers can change this
+ setting.
</para>
</listitem>
</varlistentry>
@@ -7433,9 +7432,9 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
</term>
<listitem>
<para>
- Enables collection of statistics on database activity.
+ Enables tracking of database activity.
This parameter is on by default, because the autovacuum
- daemon needs the collected information.
+ daemon needs the activity information.
Only superusers can change this setting.
</para>
</listitem>
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index f49f5c0108..45095857eb 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -2217,12 +2217,13 @@ HINT: You can then restart the server after making the necessary configuration
</para>
<para>
- The statistics collector is active during recovery. All scans, reads, blocks,
- index usage, etc., will be recorded normally on the standby. Replayed
- actions will not duplicate their effects on primary, so replaying an
- insert will not increment the Inserts column of pg_stat_user_tables.
- The stats file is deleted at the start of recovery, so stats from primary
- and standby will differ; this is considered a feature, not a bug.
+ The activity statistics is collected during recovery. All scans, reads,
+ blocks, index usage, etc., will be recorded normally on the
+ standby. Replayed actions will not duplicate their effects on primary, so
+ replaying an insert will not increment the Inserts column of
+ pg_stat_user_tables. The activity statistics is reset at the start of
+ recovery, so stats from primary and standby will differ; this is
+ considered a feature, not a bug.
</para>
<para>
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index db4b4e460c..90cf3072ac 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -22,7 +22,7 @@
<para>
Several tools are available for monitoring database activity and
analyzing performance. Most of this chapter is devoted to describing
- <productname>PostgreSQL</productname>'s statistics collector,
+ <productname>PostgreSQL</productname>'s activity statistics,
but one should not neglect regular Unix monitoring programs such as
<command>ps</command>, <command>top</command>, <command>iostat</command>, and <command>vmstat</command>.
Also, once one has identified a
@@ -53,7 +53,6 @@ postgres 15554 0.0 0.0 57536 1184 ? Ss 18:02 0:00 postgres: back
postgres 15555 0.0 0.0 57536 916 ? Ss 18:02 0:00 postgres: checkpointer
postgres 15556 0.0 0.0 57536 916 ? Ss 18:02 0:00 postgres: walwriter
postgres 15557 0.0 0.0 58504 2244 ? Ss 18:02 0:00 postgres: autovacuum launcher
-postgres 15558 0.0 0.0 17512 1068 ? Ss 18:02 0:00 postgres: stats collector
postgres 15582 0.0 0.0 58772 3080 ? Ss 18:04 0:00 postgres: joe runbug 127.0.0.1 idle
postgres 15606 0.0 0.0 58772 3052 ? Ss 18:07 0:00 postgres: tgl regression [local] SELECT waiting
postgres 15610 0.0 0.0 58772 3056 ? Ss 18:07 0:00 postgres: tgl regression [local] idle in transaction
@@ -65,9 +64,8 @@ postgres 15610 0.0 0.0 58772 3056 ? Ss 18:07 0:00 postgres: tgl
primary server process. The command arguments
shown for it are the same ones used when it was launched. The next five
processes are background worker processes automatically launched by the
- primary process. (The <quote>stats collector</quote> process will not be present
- if you have set the system not to start the statistics collector; likewise
- the <quote>autovacuum launcher</quote> process can be disabled.)
+ primary process. (The <quote>autovacuum launcher</quote> process will not
+ be present if you have set the system not to start it.)
Each of the remaining
processes is a server process handling one client connection. Each such
process sets its command line display in the form
@@ -130,20 +128,21 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
</sect1>
<sect1 id="monitoring-stats">
- <title>The Statistics Collector</title>
+ <title>The Activity Statistics</title>
<indexterm zone="monitoring-stats">
<primary>statistics</primary>
</indexterm>
<para>
- <productname>PostgreSQL</productname>'s <firstterm>statistics collector</firstterm>
- is a subsystem that supports collection and reporting of information about
- server activity. Presently, the collector can count accesses to tables
- and indexes in both disk-block and individual-row terms. It also tracks
- the total number of rows in each table, and information about vacuum and
- analyze actions for each table. It can also count calls to user-defined
- functions and the total time spent in each one.
+ <productname>PostgreSQL</productname>'s <firstterm>activity
+ statistics</firstterm> is a subsystem that supports tracking and reporting
+ of information about server activity. Presently, the activity statistics
+ tracks the count of accesses to tables and indexes in both disk-block and
+ individual-row terms. It also tracks the total number of rows in each
+ table, and information about vacuum and analyze actions for each table. It
+ can also track calls to user-defined functions and the total time spent in
+ each one.
</para>
<para>
@@ -151,15 +150,15 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
information about exactly what is going on in the system right now, such as
the exact command currently being executed by other server processes, and
which other connections exist in the system. This facility is independent
- of the collector process.
+ of the activity statistics.
</para>
<sect2 id="monitoring-stats-setup">
- <title>Statistics Collection Configuration</title>
+ <title>Activity Statistics Configuration</title>
<para>
- Since collection of statistics adds some overhead to query execution,
- the system can be configured to collect or not collect information.
+ Since tracking for the activity statistics adds some overhead to query
+ execution, the system can be configured to track or not track activity.
This is controlled by configuration parameters that are normally set in
<filename>postgresql.conf</filename>. (See <xref linkend="runtime-config"/> for
details about setting configuration parameters.)
@@ -172,7 +171,7 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<para>
The parameter <xref linkend="guc-track-counts"/> controls whether
- statistics are collected about table and index accesses.
+ to track activity about table and index accesses.
</para>
<para>
@@ -201,18 +200,11 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
</para>
<para>
- The statistics collector transmits the collected information to other
- <productname>PostgreSQL</productname> processes through temporary files.
- These files are stored in the directory named by the
- <xref linkend="guc-stats-temp-directory"/> parameter,
- <filename>pg_stat_tmp</filename> by default.
- For better performance, <varname>stats_temp_directory</varname> can be
- pointed at a RAM-based file system, decreasing physical I/O requirements.
- When the server shuts down cleanly, a permanent copy of the statistics
- data is stored in the <filename>pg_stat</filename> subdirectory, so that
- statistics can be retained across server restarts. When recovery is
- performed at server start (e.g., after immediate shutdown, server crash,
- and point-in-time recovery), all statistics counters are reset.
+ down cleanly, a permanent copy of the statistics data is stored in
+ the <filename>pg_stat</filename> subdirectory, so that statistics can be
+ retained across server restarts. When recovery is performed at server
+ start (e.g. after immediate shutdown, server crash, and point-in-time
+ recovery), all statistics counters are reset.
</para>
</sect2>
@@ -225,48 +217,46 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
linkend="monitoring-stats-dynamic-views-table"/>, are available to show
the current state of the system. There are also several other
views, listed in <xref
- linkend="monitoring-stats-views-table"/>, available to show the results
- of statistics collection. Alternatively, one can
- build custom views using the underlying statistics functions, as discussed
- in <xref linkend="monitoring-stats-functions"/>.
+ linkend="monitoring-stats-views-table"/>, available to show the activity
+ statistics. Alternatively, one can build custom views using the underlying
+ statistics functions, as discussed in
+ <xref linkend="monitoring-stats-functions"/>.
</para>
<para>
- When using the statistics to monitor collected data, it is important
- to realize that the information does not update instantaneously.
- Each individual server process transmits new statistical counts to
- the collector just before going idle; so a query or transaction still in
- progress does not affect the displayed totals. Also, the collector itself
- emits a new report at most once per <varname>PGSTAT_STAT_INTERVAL</varname>
- milliseconds (500 ms unless altered while building the server). So the
- displayed information lags behind actual activity. However, current-query
- information collected by <varname>track_activities</varname> is
- always up-to-date.
+ When using the activity statistics, it is important to realize that the
+ information does not update instantaneously. Each individual server writes
+ out new statistical counts just before going idle, not frequent than once
+ per <varname>PGSTAT_STAT_INTERVAL</varname> milliseconds (1 second unless
+ altered while building the server); so a query or transaction still in
+ progress does not affect the displayed totals. However, current-query
+ information tracked by <varname>track_activities</varname> is always
+ up-to-date.
</para>
<para>
Another important point is that when a server process is asked to display
- any of these statistics, it first fetches the most recent report emitted by
- the collector process and then continues to use this snapshot for all
- statistical views and functions until the end of its current transaction.
- So the statistics will show static information as long as you continue the
- current transaction. Similarly, information about the current queries of
- all sessions is collected when any such information is first requested
- within a transaction, and the same information will be displayed throughout
- the transaction.
- This is a feature, not a bug, because it allows you to perform several
- queries on the statistics and correlate the results without worrying that
- the numbers are changing underneath you. But if you want to see new
- results with each query, be sure to do the queries outside any transaction
- block. Alternatively, you can invoke
+ any of these statistics, it first reads the current statistics and then
+ continues to use this snapshot for all statistical views and functions
+ until the end of its current transaction. So the statistics will show
+ static information as long as you continue the current transaction.
+ Similarly, information about the current queries of all sessions is tracked
+ when any such information is first requested within a transaction, and the
+ same information will be displayed throughout the transaction. This is a
+ feature, not a bug, because it allows you to perform several queries on the
+ statistics and correlate the results without worrying that the numbers are
+ changing underneath you. But if you want to see new results with each
+ query, be sure to do the queries outside any transaction block.
+ Alternatively, you can invoke
<function>pg_stat_clear_snapshot</function>(), which will discard the
current transaction's statistics snapshot (if any). The next use of
statistical information will cause a new snapshot to be fetched.
</para>
-
+
<para>
- A transaction can also see its own statistics (as yet untransmitted to the
- collector) in the views <structname>pg_stat_xact_all_tables</structname>,
+ A transaction can also see its own statistics (as yet unwritten to the
+ server-wide activity statistics) in the
+ views <structname>pg_stat_xact_all_tables</structname>,
<structname>pg_stat_xact_sys_tables</structname>,
<structname>pg_stat_xact_user_tables</structname>, and
<structname>pg_stat_xact_user_functions</structname>. These numbers do not act as
@@ -648,7 +638,7 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
kernel's I/O cache, and might therefore still be fetched without
requiring a physical read. Users interested in obtaining more
detailed information on <productname>PostgreSQL</productname> I/O behavior are
- advised to use the <productname>PostgreSQL</productname> statistics collector
+ advised to use the <productname>PostgreSQL</productname> activity statistics
in combination with operating system utilities that allow insight
into the kernel's handling of I/O.
</para>
@@ -1086,10 +1076,6 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<entry><literal>LogicalLauncherMain</literal></entry>
<entry>Waiting in main loop of logical replication launcher process.</entry>
</row>
- <row>
- <entry><literal>PgStatMain</literal></entry>
- <entry>Waiting in main loop of statistics collector process.</entry>
- </row>
<row>
<entry><literal>RecoveryWalStream</literal></entry>
<entry>Waiting in main loop of startup process for WAL to arrive, during
@@ -1852,6 +1838,10 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
</thead>
<tbody>
+ <row>
+ <entry><literal>ActivityStatistics</literal></entry>
+ <entry>Waiting to write out activity statistics to shared memory.</entry>
+ </row>
<row>
<entry><literal>AddinShmemInit</literal></entry>
<entry>Waiting to manage an extension's space allocation in shared
@@ -6128,9 +6118,10 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<entry><literal>performing final cleanup</literal></entry>
<entry>
<command>VACUUM</command> is performing final cleanup. During this phase,
- <command>VACUUM</command> will vacuum the free space map, update statistics
- in <literal>pg_class</literal>, and report statistics to the statistics
- collector. When this phase is completed, <command>VACUUM</command> will end.
+ <command>VACUUM</command> will vacuum the free space map, update
+ statistics in <literal>pg_class</literal>, and system-wide activity
+ statistics. When this phase is completed, <command>VACUUM</command>
+ will end.
</entry>
</row>
</tbody>
diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml
index bcbb7a25fb..1fa59a2fdf 100644
--- a/doc/src/sgml/ref/pg_dump.sgml
+++ b/doc/src/sgml/ref/pg_dump.sgml
@@ -1280,11 +1280,10 @@ PostgreSQL documentation
</para>
<para>
- The database activity of <application>pg_dump</application> is
- normally collected by the statistics collector. If this is
- undesirable, you can set parameter <varname>track_counts</varname>
- to false via <envar>PGOPTIONS</envar> or the <literal>ALTER
- USER</literal> command.
+ The database activity of <application>pg_dump</application> is normally
+ collected. If this is undesirable, you can set
+ parameter <varname>track_counts</varname> to false
+ via <envar>PGOPTIONS</envar> or the <literal>ALTER USER</literal> command.
</para>
</refsect1>
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index 5d5802f61d..b5a37b5e0c 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -6328,8 +6328,6 @@ restore_backend_variables(BackendParameters *param, Port *port)
if (postmaster_alive_fds[1] >= 0)
ReserveExternalFD();
#endif
- if (pgStatSock != PGINVALID_SOCKET)
- ReserveExternalFD();
}
--
2.27.0
----Next_Part(Tue_Mar_16_10_27_55_2021_500)--
Content-Type: Text/X-Patch; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="v56-0005-Remove-the-GUC-stats_temp_directory.patch"
^ permalink raw reply [nested|flat] 13+ messages in thread
* Doc: shared_memory_size_in_huge_pages with the "SHOW" command.
@ 2024-10-11 08:25 Seino Yuki <[email protected]>
2024-10-16 00:31 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
2024-10-16 01:46 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. David G. Johnston <[email protected]>
0 siblings, 2 replies; 13+ messages in thread
From: Seino Yuki @ 2024-10-11 08:25 UTC (permalink / raw)
To: pgsql-hackers
Hello,
Add a reference method for shared_memory_size_in_huge_pages
with the "SHOW" command.
The current documentation explains the use of the postgres -C command,
but this method may be limited in DBaaS or managed service environments.
In particular, CloudNativePG does not allow the server to be stopped,
making the execution of $ postgres -C impossible.
Alternatively, the "SHOW" command can be used, though the documentation
states,
"Note that the server must be shut down to view this runtime-computed
parameter.[1]"
This wording could be misunderstood to imply that the parameter cannot
be accessed
while the server is running.
[1] -
https://www.postgresql.org/docs/devel/kernel-resources.html#LINUX-HUGE-PAGES
Regards,
--
Yuki Seino
NTT DATA CORPORATION
Attachments:
[text/x-diff] v1-0001-shared_memory_size_in_huge_pages_using_show.patch (809B, ../../[email protected]/2-v1-0001-shared_memory_size_in_huge_pages_using_show.patch)
download | inline diff:
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 2c4d5ef640..aaac025c90 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1441,6 +1441,17 @@ $ <userinput>grep ^Hugepagesize /proc/meminfo</userinput>
Hugepagesize: 2048 kB
$ <userinput>ls /sys/kernel/mm/hugepages</userinput>
hugepages-1048576kB hugepages-2048kB
+</programlisting>
+
+ If the server is running, this parameter can be viewed using the
+ <command>SHOW</command> command.
+ This might look like:
+<programlisting>
+postgres=# <userinput>SHOW shared_memory_size_in_huge_pages;</userinput>
+ shared_memory_size_in_huge_pages
+----------------------------------
+ 3170
+(1 row)
</programlisting>
In this example the default is 2MB, but you can also explicitly request
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command.
2024-10-11 08:25 Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Seino Yuki <[email protected]>
@ 2024-10-16 00:31 ` Michael Paquier <[email protected]>
2024-10-16 01:26 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
1 sibling, 1 reply; 13+ messages in thread
From: Michael Paquier @ 2024-10-16 00:31 UTC (permalink / raw)
To: Seino Yuki <[email protected]>; +Cc: pgsql-hackers
On Fri, Oct 11, 2024 at 05:25:04PM +0900, Seino Yuki wrote:
> Alternatively, the "SHOW" command can be used, though the documentation
> states,
> "Note that the server must be shut down to view this runtime-computed
> parameter.[1]"
> This wording could be misunderstood to imply that the parameter cannot be
> accessed
> while the server is running.
I am not sure that neither mentioning nor recommending SHOW for this
area is a good idea, the point being to encourage its use before the
server is running as we don't want to allocate anything when tuning
it.
Point taken that the current wording can be confusing because of the
"*must* be shut down". How about doing a simpler s/must/should/ for a
softer wording?
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command.
2024-10-11 08:25 Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Seino Yuki <[email protected]>
2024-10-16 00:31 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
@ 2024-10-16 01:26 ` Nathan Bossart <[email protected]>
2024-10-16 05:18 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
0 siblings, 1 reply; 13+ messages in thread
From: Nathan Bossart @ 2024-10-16 01:26 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Seino Yuki <[email protected]>; pgsql-hackers
On Wed, Oct 16, 2024 at 09:31:49AM +0900, Michael Paquier wrote:
> I am not sure that neither mentioning nor recommending SHOW for this
> area is a good idea, the point being to encourage its use before the
> server is running as we don't want to allocate anything when tuning
> it.
Agreed.
> Point taken that the current wording can be confusing because of the
> "*must* be shut down". How about doing a simpler s/must/should/ for a
> softer wording?
Well, the point is that you can't use "postgres -C" to view this GUC while
the server is running. I can see how the present wording might be
misinterpreted, though. Perhaps we should change this sentence to
something like:
Note that the server must be shut down to view this runtime-computed
parameter with the postgres command.
--
nathan
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command.
2024-10-11 08:25 Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Seino Yuki <[email protected]>
2024-10-16 00:31 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
2024-10-16 01:26 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
@ 2024-10-16 05:18 ` Michael Paquier <[email protected]>
2024-10-16 06:31 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Fujii Masao <[email protected]>
0 siblings, 1 reply; 13+ messages in thread
From: Michael Paquier @ 2024-10-16 05:18 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Seino Yuki <[email protected]>; pgsql-hackers
On Tue, Oct 15, 2024 at 08:26:06PM -0500, Nathan Bossart wrote:
> Well, the point is that you can't use "postgres -C" to view this GUC while
> the server is running. I can see how the present wording might be
> misinterpreted, though. Perhaps we should change this sentence to
> something like:
>
> Note that the server must be shut down to view this runtime-computed
> parameter with the postgres command.
I'm OK with the "postgres command" addition.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command.
2024-10-11 08:25 Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Seino Yuki <[email protected]>
2024-10-16 00:31 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
2024-10-16 01:26 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
2024-10-16 05:18 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
@ 2024-10-16 06:31 ` Fujii Masao <[email protected]>
2024-10-16 14:44 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
0 siblings, 1 reply; 13+ messages in thread
From: Fujii Masao @ 2024-10-16 06:31 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; Nathan Bossart <[email protected]>; +Cc: Seino Yuki <[email protected]>; pgsql-hackers
On 2024/10/16 14:18, Michael Paquier wrote:
> On Tue, Oct 15, 2024 at 08:26:06PM -0500, Nathan Bossart wrote:
>> Well, the point is that you can't use "postgres -C" to view this GUC while
>> the server is running. I can see how the present wording might be
>> misinterpreted, though. Perhaps we should change this sentence to
>> something like:
>>
>> Note that the server must be shut down to view this runtime-computed
>> parameter with the postgres command.
>
> I'm OK with the "postgres command" addition.
Another idea is to use the same wording as for num_os_semaphores in runtime.sgml, like this:
This parameter can be viewed
before starting the server with a <command>postgres</command> command like:
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command.
2024-10-11 08:25 Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Seino Yuki <[email protected]>
2024-10-16 00:31 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
2024-10-16 01:26 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
2024-10-16 05:18 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
2024-10-16 06:31 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Fujii Masao <[email protected]>
@ 2024-10-16 14:44 ` Nathan Bossart <[email protected]>
2024-10-17 05:07 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Seino Yuki <[email protected]>
0 siblings, 1 reply; 13+ messages in thread
From: Nathan Bossart @ 2024-10-16 14:44 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: Michael Paquier <[email protected]>; Seino Yuki <[email protected]>; pgsql-hackers
On Wed, Oct 16, 2024 at 03:31:05PM +0900, Fujii Masao wrote:
> Another idea is to use the same wording as for num_os_semaphores in runtime.sgml, like this:
>
> This parameter can be viewed
> before starting the server with a <command>postgres</command> command like:
WFM
--
nathan
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command.
2024-10-11 08:25 Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Seino Yuki <[email protected]>
2024-10-16 00:31 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
2024-10-16 01:26 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
2024-10-16 05:18 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
2024-10-16 06:31 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Fujii Masao <[email protected]>
2024-10-16 14:44 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
@ 2024-10-17 05:07 ` Seino Yuki <[email protected]>
2024-10-17 21:59 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
0 siblings, 1 reply; 13+ messages in thread
From: Seino Yuki @ 2024-10-17 05:07 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Fujii Masao <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
Thank you, everyone.
> the point being to encourage its use before the server is running
> as we don't want to allocate anything when tuning it.
I was mistaken and now understand that it needs to be run before the
server is running.
>> Another idea is to use the same wording as for num_os_semaphores in
>> runtime.sgml, like this:
>
> WFM
I've fixed the patch and will register it in the CF.
Regards,
--
Yuki Seino
NTT DATA CORPORATION
Attachments:
[text/x-diff] v2-0001-shared_memory_size_in_huge_pages_docfix.patch (871B, ../../[email protected]/2-v2-0001-shared_memory_size_in_huge_pages_docfix.patch)
download | inline diff:
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 2c4d5ef640..63669f2d2e 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1431,9 +1431,9 @@ export PG_OOM_ADJUST_VALUE=0
the operating system to provide enough huge pages of the desired size.
To determine the number of huge pages needed, use the
<command>postgres</command> command to see the value of
- <xref linkend="guc-shared-memory-size-in-huge-pages"/>. Note that the
- server must be shut down to view this runtime-computed parameter.
- This might look like:
+ <xref linkend="guc-shared-memory-size-in-huge-pages"/>. This parameter
+ can be viewed before starting the server with a <command>postgres</command>
+ command like:
<programlisting>
$ <userinput>postgres -D $PGDATA -C shared_memory_size_in_huge_pages</userinput>
3170
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command.
2024-10-11 08:25 Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Seino Yuki <[email protected]>
2024-10-16 00:31 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
2024-10-16 01:26 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
2024-10-16 05:18 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
2024-10-16 06:31 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Fujii Masao <[email protected]>
2024-10-16 14:44 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
2024-10-17 05:07 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Seino Yuki <[email protected]>
@ 2024-10-17 21:59 ` Nathan Bossart <[email protected]>
2024-10-17 22:10 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
0 siblings, 1 reply; 13+ messages in thread
From: Nathan Bossart @ 2024-10-17 21:59 UTC (permalink / raw)
To: Seino Yuki <[email protected]>; +Cc: Fujii Masao <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On Thu, Oct 17, 2024 at 02:07:32PM +0900, Seino Yuki wrote:
> I've fixed the patch and will register it in the CF.
Thanks. Here is what I have staged for commit.
--
nathan
From 8aff8ec54a6588614f952693f509b75bf240851c Mon Sep 17 00:00:00 2001
From: Nathan Bossart <[email protected]>
Date: Thu, 17 Oct 2024 16:56:52 -0500
Subject: [PATCH v3 1/1] Adjust documentation for configuring Linux huge pages.
The present wording about viewing shared_memory_size_in_huge_pages
seems to suggest that the parameter cannot be viewed after startup
at all, whereas the intent is to make it clear that you can't use
"postgres -C" to view this GUC while the server is running. This
commit rephrases this section to remove the ambiguity.
Author: Seino Yuki
Reviewed-by: Michael Paquier, David G. Johnston, Fujii Masao
Discussion: https://postgr.es/m/420584fd274f9ec4f337da55ffb3b790%40oss.nttdata.com
Backpatch-through: 15
---
doc/src/sgml/runtime.sgml | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 2c4d5ef640..a47fa67b38 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1429,11 +1429,10 @@ export PG_OOM_ADJUST_VALUE=0
with <varname>CONFIG_HUGETLBFS=y</varname> and
<varname>CONFIG_HUGETLB_PAGE=y</varname>. You will also have to configure
the operating system to provide enough huge pages of the desired size.
- To determine the number of huge pages needed, use the
- <command>postgres</command> command to see the value of
- <xref linkend="guc-shared-memory-size-in-huge-pages"/>. Note that the
- server must be shut down to view this runtime-computed parameter.
- This might look like:
+ The runtime-computed parameter
+ <xref linkend="guc-shared-memory-size-in-huge-pages"/> reports the number
+ of huge pages required. This parameter can be viewed before starting the
+ server with a <command>postgres</command> command like:
<programlisting>
$ <userinput>postgres -D $PGDATA -C shared_memory_size_in_huge_pages</userinput>
3170
--
2.39.5 (Apple Git-154)
Attachments:
[text/plain] v3-0001-Adjust-documentation-for-configuring-Linux-huge-p.patch (1.9K, ../../ZxGI2pYl9cI9wAKB@nathan/2-v3-0001-Adjust-documentation-for-configuring-Linux-huge-p.patch)
download | inline diff:
From 8aff8ec54a6588614f952693f509b75bf240851c Mon Sep 17 00:00:00 2001
From: Nathan Bossart <[email protected]>
Date: Thu, 17 Oct 2024 16:56:52 -0500
Subject: [PATCH v3 1/1] Adjust documentation for configuring Linux huge pages.
The present wording about viewing shared_memory_size_in_huge_pages
seems to suggest that the parameter cannot be viewed after startup
at all, whereas the intent is to make it clear that you can't use
"postgres -C" to view this GUC while the server is running. This
commit rephrases this section to remove the ambiguity.
Author: Seino Yuki
Reviewed-by: Michael Paquier, David G. Johnston, Fujii Masao
Discussion: https://postgr.es/m/420584fd274f9ec4f337da55ffb3b790%40oss.nttdata.com
Backpatch-through: 15
---
doc/src/sgml/runtime.sgml | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 2c4d5ef640..a47fa67b38 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1429,11 +1429,10 @@ export PG_OOM_ADJUST_VALUE=0
with <varname>CONFIG_HUGETLBFS=y</varname> and
<varname>CONFIG_HUGETLB_PAGE=y</varname>. You will also have to configure
the operating system to provide enough huge pages of the desired size.
- To determine the number of huge pages needed, use the
- <command>postgres</command> command to see the value of
- <xref linkend="guc-shared-memory-size-in-huge-pages"/>. Note that the
- server must be shut down to view this runtime-computed parameter.
- This might look like:
+ The runtime-computed parameter
+ <xref linkend="guc-shared-memory-size-in-huge-pages"/> reports the number
+ of huge pages required. This parameter can be viewed before starting the
+ server with a <command>postgres</command> command like:
<programlisting>
$ <userinput>postgres -D $PGDATA -C shared_memory_size_in_huge_pages</userinput>
3170
--
2.39.5 (Apple Git-154)
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command.
2024-10-11 08:25 Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Seino Yuki <[email protected]>
2024-10-16 00:31 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
2024-10-16 01:26 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
2024-10-16 05:18 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
2024-10-16 06:31 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Fujii Masao <[email protected]>
2024-10-16 14:44 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
2024-10-17 05:07 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Seino Yuki <[email protected]>
2024-10-17 21:59 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
@ 2024-10-17 22:10 ` Michael Paquier <[email protected]>
2024-10-18 05:47 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Fujii Masao <[email protected]>
0 siblings, 1 reply; 13+ messages in thread
From: Michael Paquier @ 2024-10-17 22:10 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Seino Yuki <[email protected]>; Fujii Masao <[email protected]>; pgsql-hackers
On Thu, Oct 17, 2024 at 04:59:54PM -0500, Nathan Bossart wrote:
> Thanks. Here is what I have staged for commit.
Fine by me. Thanks.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command.
2024-10-11 08:25 Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Seino Yuki <[email protected]>
2024-10-16 00:31 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
2024-10-16 01:26 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
2024-10-16 05:18 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
2024-10-16 06:31 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Fujii Masao <[email protected]>
2024-10-16 14:44 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
2024-10-17 05:07 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Seino Yuki <[email protected]>
2024-10-17 21:59 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
2024-10-17 22:10 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
@ 2024-10-18 05:47 ` Fujii Masao <[email protected]>
2024-10-18 15:22 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
0 siblings, 1 reply; 13+ messages in thread
From: Fujii Masao @ 2024-10-18 05:47 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; Nathan Bossart <[email protected]>; +Cc: Seino Yuki <[email protected]>; pgsql-hackers
On 2024/10/18 7:10, Michael Paquier wrote:
> On Thu, Oct 17, 2024 at 04:59:54PM -0500, Nathan Bossart wrote:
>> Thanks. Here is what I have staged for commit.
>
> Fine by me. Thanks.
LGTM, too. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command.
2024-10-11 08:25 Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Seino Yuki <[email protected]>
2024-10-16 00:31 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
2024-10-16 01:26 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
2024-10-16 05:18 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
2024-10-16 06:31 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Fujii Masao <[email protected]>
2024-10-16 14:44 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
2024-10-17 05:07 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Seino Yuki <[email protected]>
2024-10-17 21:59 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
2024-10-17 22:10 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
2024-10-18 05:47 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Fujii Masao <[email protected]>
@ 2024-10-18 15:22 ` Nathan Bossart <[email protected]>
0 siblings, 0 replies; 13+ messages in thread
From: Nathan Bossart @ 2024-10-18 15:22 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: Michael Paquier <[email protected]>; Seino Yuki <[email protected]>; pgsql-hackers
On Fri, Oct 18, 2024 at 02:47:37PM +0900, Fujii Masao wrote:
> On 2024/10/18 7:10, Michael Paquier wrote:
>> Fine by me. Thanks.
>
> LGTM, too. Thanks!
Committed.
--
nathan
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command.
2024-10-11 08:25 Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Seino Yuki <[email protected]>
@ 2024-10-16 01:46 ` David G. Johnston <[email protected]>
1 sibling, 0 replies; 13+ messages in thread
From: David G. Johnston @ 2024-10-16 01:46 UTC (permalink / raw)
To: Seino Yuki <[email protected]>; +Cc: pgsql-hackers
On Friday, October 11, 2024, Seino Yuki <[email protected]> wrote:
>
>
> The current documentation explains the use of the postgres -C command,
> but this method may be limited in DBaaS or managed service environments.
> In particular, CloudNativePG does not allow the server to be stopped,
> making the execution of $ postgres -C impossible.
If your environment doesn’t allow shutting down the Postgres service it
seems highly unlikely you’d be able to perform the other low-level
operating system actions required here as well.
I think the wording is fine as-is, though for consistency with an earlier
mention on the page we could instead write:
This parameter can be viewed before starting the server with a postgres command
like:
David J.
^ permalink raw reply [nested|flat] 13+ messages in thread
end of thread, other threads:[~2024-10-18 15:22 UTC | newest]
Thread overview: 13+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-03-19 06:11 [PATCH v56 4/6] Doc part of shared-memory based stats collector. Kyotaro Horiguchi <[email protected]>
2024-10-11 08:25 Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Seino Yuki <[email protected]>
2024-10-16 00:31 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
2024-10-16 01:26 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
2024-10-16 05:18 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
2024-10-16 06:31 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Fujii Masao <[email protected]>
2024-10-16 14:44 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
2024-10-17 05:07 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Seino Yuki <[email protected]>
2024-10-17 21:59 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
2024-10-17 22:10 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Michael Paquier <[email protected]>
2024-10-18 05:47 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Fujii Masao <[email protected]>
2024-10-18 15:22 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. Nathan Bossart <[email protected]>
2024-10-16 01:46 ` Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command. David G. Johnston <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox