public inbox for [email protected]help / color / mirror / Atom feed
[PATCH 3/6] Add backlinks to progress reporting documentation 3+ messages / 3 participants [nested] [flat]
* [PATCH 3/6] Add backlinks to progress reporting documentation @ 2021-02-05 22:11 Matthias van de Meent <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Matthias van de Meent @ 2021-02-05 22:11 UTC (permalink / raw) Previously, for most progress-reported features, the only place the feature was mentioned is in the progress reporting document itself. This makes the progress reporting more discoverable from the reported commands. --- doc/src/sgml/ref/analyze.sgml | 7 +++++++ doc/src/sgml/ref/cluster.sgml | 6 ++++++ doc/src/sgml/ref/copy.sgml | 14 ++++++++++++++ doc/src/sgml/ref/create_index.sgml | 8 ++++++++ doc/src/sgml/ref/pg_basebackup.sgml | 1 + doc/src/sgml/ref/reindex.sgml | 7 +++++++ doc/src/sgml/ref/vacuum.sgml | 11 +++++++++++ 7 files changed, 54 insertions(+) diff --git a/doc/src/sgml/ref/analyze.sgml b/doc/src/sgml/ref/analyze.sgml index 7d816c87c6..9db9070b62 100644 --- a/doc/src/sgml/ref/analyze.sgml +++ b/doc/src/sgml/ref/analyze.sgml @@ -273,6 +273,12 @@ ANALYZE [ VERBOSE ] [ <replaceable class="parameter">table_and_columns</replacea will not record new statistics for that table. Any existing statistics will be retained. </para> + + <para> + Each backend running the <command>ANALYZE</command> command will report their + progress to the <structname>pg_stat_progress_analyze</structname> view. + See <xref linkend="analyze-progress-reporting"/> for details. + </para> </refsect1> <refsect1> @@ -291,6 +297,7 @@ ANALYZE [ VERBOSE ] [ <replaceable class="parameter">table_and_columns</replacea <member><xref linkend="app-vacuumdb"/></member> <member><xref linkend="runtime-config-resource-vacuum-cost"/></member> <member><xref linkend="autovacuum"/></member> + <member><xref linkend="analyze-progress-reporting"/></member> </simplelist> </refsect1> </refentry> diff --git a/doc/src/sgml/ref/cluster.sgml b/doc/src/sgml/ref/cluster.sgml index 5dd21a0189..5c2270f71b 100644 --- a/doc/src/sgml/ref/cluster.sgml +++ b/doc/src/sgml/ref/cluster.sgml @@ -192,6 +192,11 @@ CLUSTER [VERBOSE] are periodically reclustered. </para> + <para> + Each backend running the <command>CLUSTER</command> command will report their + progress to the <structname>pg_stat_progress_cluster</structname> view. + See <xref linkend="cluster-progress-reporting"/> for details. + </para> </refsect1> <refsect1> @@ -242,6 +247,7 @@ CLUSTER <replaceable class="parameter">index_name</replaceable> ON <replaceable <simplelist type="inline"> <member><xref linkend="app-clusterdb"/></member> + <member><xref linkend="cluster-progress-reporting"/></member> </simplelist> </refsect1> </refentry> diff --git a/doc/src/sgml/ref/copy.sgml b/doc/src/sgml/ref/copy.sgml index 0fca6583af..af3ce72561 100644 --- a/doc/src/sgml/ref/copy.sgml +++ b/doc/src/sgml/ref/copy.sgml @@ -82,6 +82,12 @@ COPY { <replaceable class="parameter">table_name</replaceable> [ ( <replaceable specified, data is transmitted via the connection between the client and the server. </para> + + <para> + Each backend running the <command>COPY</command> command will report their + progress to the <structname>pg_stat_progress_copy</structname> view. + See <xref linkend="copy-progress-reporting"/> for details. + </para> </refsect1> <refsect1> @@ -1052,4 +1058,12 @@ COPY [ BINARY ] <replaceable class="parameter">table_name</replaceable> [ WITH NULL AS '<replaceable class="parameter">null_string</replaceable>' ] </synopsis></para> </refsect1> + + <refsect1> + <title>See Also</title> + + <simplelist type="inline"> + <member><xref linkend="copy-progress-reporting"/></member> + </simplelist> + </refsect1> </refentry> diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml index a5271a9f8f..278058f500 100644 --- a/doc/src/sgml/ref/create_index.sgml +++ b/doc/src/sgml/ref/create_index.sgml @@ -865,6 +865,13 @@ Indexes: will interpret it as <literal>USING gist</literal>, to simplify conversion of old databases to GiST. </para> + + <para> + Each backend running the <command>CREATE INDEX</command> command will + report their progress to the + <structname>pg_stat_progress_create_index</structname> view. + See <xref linkend="create-index-progress-reporting"/> for details. + </para> </refsect1> <refsect1> @@ -978,6 +985,7 @@ CREATE INDEX CONCURRENTLY sales_quantity_index ON sales_table (quantity); <member><xref linkend="sql-alterindex"/></member> <member><xref linkend="sql-dropindex"/></member> <member><xref linkend="sql-reindex"/></member> + <member><xref linkend="create-index-progress-reporting"/></member> </simplelist> </refsect1> </refentry> diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml index 5754ad5aa6..14cc88a852 100644 --- a/doc/src/sgml/ref/pg_basebackup.sgml +++ b/doc/src/sgml/ref/pg_basebackup.sgml @@ -904,6 +904,7 @@ PostgreSQL documentation <simplelist type="inline"> <member><xref linkend="app-pgdump"/></member> + <member><xref linkend="basebackup-progress-reporting"/></member> </simplelist> </refsect1> diff --git a/doc/src/sgml/ref/reindex.sgml b/doc/src/sgml/ref/reindex.sgml index 07795b5737..f69f5db403 100644 --- a/doc/src/sgml/ref/reindex.sgml +++ b/doc/src/sgml/ref/reindex.sgml @@ -493,6 +493,12 @@ Indexes: is reindexed concurrently, those indexes will be skipped. (It is possible to reindex such indexes without the <command>CONCURRENTLY</command> option.) </para> + + <para> + Each backend running the <command>REINDEX</command> command will report + their progress to the <structname>pg_stat_progress_create_index</structname> + view. See <xref linkend="create-index-progress-reporting"/> for details. + </para> </refsect2> </refsect1> @@ -551,6 +557,7 @@ REINDEX TABLE CONCURRENTLY my_broken_table; <member><xref linkend="sql-createindex"/></member> <member><xref linkend="sql-dropindex"/></member> <member><xref linkend="app-reindexdb"/></member> + <member><xref linkend="create-index-progress-reporting"/></member> </simplelist> </refsect1> </refentry> diff --git a/doc/src/sgml/ref/vacuum.sgml b/doc/src/sgml/ref/vacuum.sgml index 4bb624979b..bab3d00313 100644 --- a/doc/src/sgml/ref/vacuum.sgml +++ b/doc/src/sgml/ref/vacuum.sgml @@ -393,6 +393,15 @@ VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ ANALYZE ] [ <replaceable class="paramet information about automatic and manual vacuuming, see <xref linkend="routine-vacuuming"/>. </para> + <para> + Each backend running the <command>VACUUM</command> command without the + <literal>FULL</literal> option will report their progress in the + <structname>pg_stat_progress_vacuum</structname> view. Backends running + <command>VACUUM</command> with the <literal>FULL</literal> option report + progress in the <structname>pg_stat_progress_cluster</structname> instead. + See <xref linkend="vacuum-progress-reporting"/> and + <xref linkend="cluster-progress-reporting"/> for details. + </para> </refsect1> <refsect1> @@ -422,6 +431,8 @@ VACUUM (VERBOSE, ANALYZE) onek; <member><xref linkend="app-vacuumdb"/></member> <member><xref linkend="runtime-config-resource-vacuum-cost"/></member> <member><xref linkend="autovacuum"/></member> + <member><xref linkend="vacuum-progress-reporting"/></member> + <member><xref linkend="cluster-progress-reporting"/></member> </simplelist> </refsect1> </refentry> -- 2.26.2 --------------DA8D60BF026F7ACE69A9AEE5 Content-Type: text/x-patch; charset=UTF-8; name="v7-0004-0002-review.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="v7-0004-0002-review.patch" ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: BF mamba failure @ 2024-10-16 00:43 Michael Paquier <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Michael Paquier @ 2024-10-16 00:43 UTC (permalink / raw) To: Bertrand Drouvot <[email protected]>; +Cc: Kouber Saparev <[email protected]>; [email protected] On Fri, Oct 11, 2024 at 08:18:58AM +0000, Bertrand Drouvot wrote: > On Fri, Oct 11, 2024 at 11:07:29AM +0300, Kouber Saparev wrote: >> Unfortunately not, we are running 15.4 and planning to upgrade very soon. >> Is the patch mentioned already merged in PostgreSQL 16? > > Yes, as of 16.4. Right. I'd surely welcome more eyes on what I have posted here: https://www.postgresql.org/message-id/[email protected] I am a bit annoyed by the fact of making PgStatShared_HashEntry slightly larger to track the age of the entries, especially as this comes down to being useful only when OID wraparound for all stats kinds (well, except replslot data, because slot IDs can be more aggressive or custom pgstats), but I don't really have a brighter idea for the reason that this is something that we need to track at entry-level to be able to tell across backends when a single stats dshash entry can or cannot be reused. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: BF mamba failure @ 2024-10-16 10:11 Bertrand Drouvot <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Bertrand Drouvot @ 2024-10-16 10:11 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Kouber Saparev <[email protected]>; [email protected] Hi, On Wed, Oct 16, 2024 at 09:43:48AM +0900, Michael Paquier wrote: > On Fri, Oct 11, 2024 at 08:18:58AM +0000, Bertrand Drouvot wrote: > > On Fri, Oct 11, 2024 at 11:07:29AM +0300, Kouber Saparev wrote: > >> Unfortunately not, we are running 15.4 and planning to upgrade very soon. > >> Is the patch mentioned already merged in PostgreSQL 16? > > > > Yes, as of 16.4. > > Right. I'd surely welcome more eyes on what I have posted here: > https://www.postgresql.org/message-id/[email protected] I applied your patch and do confirm that it fixes the issue. While that works I wonder is there no other way to fix the issue. Indeed, in pgstat_release_entry_ref(), we're doing: " if (pg_atomic_fetch_sub_u32(&entry_ref->shared_entry->refcount, 1) == 1) . . shent = dshash_find(pgStatLocal.shared_hash, &entry_ref->shared_entry->key, true); " I wonder if we are not decrementing &entry_ref->shared_entry->refcount too early. I mean, wouldn't that make sense to decrement it after the dshash_find() call? (to ensure a "proper" whole entry locking, done in dshash_find(), first) > I am a bit annoyed by the fact of making PgStatShared_HashEntry > slightly larger to track the age of the entries, Yeah, FWIW, we would be going from 32 bytes: (gdb) ptype /o struct PgStatShared_HashEntry /* offset | size */ type = struct PgStatShared_HashEntry { /* 0 | 16 */ PgStat_HashKey key; /* 16 | 1 */ _Bool dropped; /* XXX 3-byte hole */ /* 20 | 4 */ pg_atomic_uint32 refcount; /* 24 | 8 */ dsa_pointer body; /* total size (bytes): 32 */ } to 40 bytes (with the patch applied): (gdb) ptype /o struct PgStatShared_HashEntry /* offset | size */ type = struct PgStatShared_HashEntry { /* 0 | 16 */ PgStat_HashKey key; /* 16 | 1 */ _Bool dropped; /* XXX 3-byte hole */ /* 20 | 4 */ pg_atomic_uint32 refcount; /* 24 | 4 */ pg_atomic_uint32 agecount; /* XXX 4-byte hole */ /* 32 | 8 */ dsa_pointer body; /* total size (bytes): 40 */ } Due to the padding, that's a 8 bytes increase while we're adding "only" 4 bytes. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2024-10-16 10:11 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2021-02-05 22:11 [PATCH 3/6] Add backlinks to progress reporting documentation Matthias van de Meent <[email protected]> 2024-10-16 00:43 Re: BF mamba failure Michael Paquier <[email protected]> 2024-10-16 10:11 ` Re: BF mamba failure Bertrand Drouvot <[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