pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #16972: parameter parallel_leader_participation's category problem
10+ messages / 3 participants
[nested] [flat]
Commits from this thread:
2021-04-22 1599e7b375 doc: Move parallel_leader_participation to its correct category
* BUG #16972: parameter parallel_leader_participation's category problem
@ 2021-04-20 06:45 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 10+ messages in thread
From: PG Bug reporting form @ 2021-04-20 06:45 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: leiyanliang@highgo.com
The following bug has been logged on the website:
Bug reference: 16972
Logged by: yanliang lei
Email address: leiyanliang@highgo.com
PostgreSQL version: 13.1
Operating system: CentOS7.6
Description:
In the following SQL statement, parallel_leader_participation's category is
' Resource Usage / Asynchronous Behavior'
postgres=# select * from pg_settings where
name='parallel_leader_participation';
-[ RECORD 1
]---+--------------------------------------------------------------
name | parallel_leader_participation
setting | on
unit |
category | Resource Usage / Asynchronous Behavior
short_desc | Controls whether Gather and Gather Merge also run
subplans.
extra_desc | Should gather nodes also run subplans, or just gather
tuples?
context | user
vartype | bool
source | default
min_val |
max_val |
enumvals |
boot_val | on
reset_val | on
sourcefile |
sourceline |
pending_restart | f
postgres=#
but in the documents
(https://www.postgresql.org/docs/13/runtime-config-query.html#RUNTIME-CONFIG-QUERY-OTHER)
parallel_leader_participation's category is 'Query Tuning / Other Planner
Options'
and in the category "Asynchronous
Behavior"(https://www.postgresql.org/docs/13/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-ASYNC-BEHAVI...
is no parallel_leader_participation parameter.
so, what is parallel_leader_participation's category ?
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #16972: parameter parallel_leader_participation's category problem
@ 2021-04-20 08:08 Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
parent: PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 10+ messages in thread
From: Bharath Rupireddy @ 2021-04-20 08:08 UTC (permalink / raw)
To: leiyanliang@highgo.com; pgsql-bugs@lists.postgresql.org
On Tue, Apr 20, 2021 at 12:54 PM PG Bug reporting form
<noreply@postgresql.org> wrote:
>
> The following bug has been logged on the website:
>
> Bug reference: 16972
> Logged by: yanliang lei
> Email address: leiyanliang@highgo.com
> PostgreSQL version: 13.1
> Operating system: CentOS7.6
> Description:
>
> In the following SQL statement, parallel_leader_participation's category is
> ' Resource Usage / Asynchronous Behavior'
>
> postgres=# select * from pg_settings where
> name='parallel_leader_participation';
> -[ RECORD 1
> ]---+--------------------------------------------------------------
> name | parallel_leader_participation
> setting | on
> unit |
> category | Resource Usage / Asynchronous Behavior
> short_desc | Controls whether Gather and Gather Merge also run
> subplans.
> extra_desc | Should gather nodes also run subplans, or just gather
> tuples?
> context | user
> vartype | bool
> source | default
> min_val |
> max_val |
> enumvals |
> boot_val | on
> reset_val | on
> sourcefile |
> sourceline |
> pending_restart | f
>
> postgres=#
>
> but in the documents
> (https://www.postgresql.org/docs/13/runtime-config-query.html#RUNTIME-CONFIG-QUERY-OTHER)
> parallel_leader_participation's category is 'Query Tuning / Other Planner
> Options'
> and in the category "Asynchronous
> Behavior"(https://www.postgresql.org/docs/13/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-ASYNC-BEHAVI...
> is no parallel_leader_participation parameter.
>
> so, what is parallel_leader_participation's category ?
Thanks for reporting.
I think it comes under the category "Resource Usage / Asynchronous
Behavior", so what pg_settings showing is correct. ISTM that we need
to correct the docs, attached a patch for that.
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
Attachments:
v1-0001-Move-parallel_leader_participation-to-Resource-Co.patch (application/x-patch, 3.6K) download
From a26f043368173c1b690ed0d170f2d6286ba9f898 Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy <bharath.rupireddy@enterprisedb.com>
Date: Tue, 20 Apr 2021 13:32:02 +0530
Subject: [PATCH v1] Move parallel_leader_participation to Resource Consumption
Category
parallel_leader_partiticipation GUC is rightly categorized as
Resource Usage/Asynchronous Behavior parameter in the code, but in
the docs, it is still under Query Planning/Other Planner Options
category. Just move it to the correct place i.e. under Resource
Consumption/Asynchronous Behaviour.
---
doc/src/sgml/config.sgml | 46 ++++++++++++++++++++--------------------
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 776ab1a8c8..a4dcee1fc8 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2520,6 +2520,29 @@ include_dir 'conf.d'
</listitem>
</varlistentry>
+ <varlistentry id="guc-parallel-leader-participation" xreflabel="parallel_leader_participation">
+ <term>
+ <varname>parallel_leader_participation</varname> (<type>boolean</type>)
+ <indexterm>
+ <primary><varname>parallel_leader_participation</varname> configuration parameter</primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ Allows the leader process to execute the query plan under
+ <literal>Gather</literal> and <literal>Gather Merge</literal> nodes
+ instead of waiting for worker processes. The default is
+ <literal>on</literal>. Setting this value to <literal>off</literal>
+ reduces the likelihood that workers will become blocked because the
+ leader is not reading tuples fast enough, but requires the leader
+ process to wait for worker processes to start up before the first
+ tuples can be produced. The degree to which the leader can help or
+ hinder performance depends on the plan type, number of workers and
+ query duration.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="guc-max-parallel-maintenance-workers" xreflabel="max_parallel_maintenance_workers">
<term><varname>max_parallel_maintenance_workers</varname> (<type>integer</type>)
<indexterm>
@@ -5889,29 +5912,6 @@ SELECT * FROM parent WHERE key = 2400;
</listitem>
</varlistentry>
- <varlistentry id="guc-parallel-leader-participation" xreflabel="parallel_leader_participation">
- <term>
- <varname>parallel_leader_participation</varname> (<type>boolean</type>)
- <indexterm>
- <primary><varname>parallel_leader_participation</varname> configuration parameter</primary>
- </indexterm>
- </term>
- <listitem>
- <para>
- Allows the leader process to execute the query plan under
- <literal>Gather</literal> and <literal>Gather Merge</literal> nodes
- instead of waiting for worker processes. The default is
- <literal>on</literal>. Setting this value to <literal>off</literal>
- reduces the likelihood that workers will become blocked because the
- leader is not reading tuples fast enough, but requires the leader
- process to wait for worker processes to start up before the first
- tuples can be produced. The degree to which the leader can help or
- hinder performance depends on the plan type, number of workers and
- query duration.
- </para>
- </listitem>
- </varlistentry>
-
<varlistentry id="guc-plan-cache_mode" xreflabel="plan_cache_mode">
<term><varname>plan_cache_mode</varname> (<type>enum</type>)
<indexterm>
--
2.25.1
* Re: BUG #16972: parameter parallel_leader_participation's category problem
@ 2021-04-21 02:46 Michael Paquier <michael@paquier.xyz>
parent: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: Michael Paquier @ 2021-04-21 02:46 UTC (permalink / raw)
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>; +Cc: leiyanliang@highgo.com; pgsql-bugs@lists.postgresql.org
On Tue, Apr 20, 2021 at 01:38:48PM +0530, Bharath Rupireddy wrote:
> I think it comes under the category "Resource Usage / Asynchronous
> Behavior", so what pg_settings showing is correct. ISTM that we need
> to correct the docs, attached a patch for that.
This got introduced in e5253fd. My first impression was that this
had better be a developer option, but Thomas is mentioning an extra
reason why this category may not be a good fit:
https://www.postgresql.org/message-id/CAEepm=3G1-SKd2qKN-3uen=Xvyi-OxAVg9RAwqWDH-KZWuGqNA@mail.gmail...
And Robert has moved that at the end to its GUC section without
addressing the docs:
https://www.postgresql.org/message-id/CA+Tgmoa=AxuLKo2f1AKwLmvFoo3rr3j+SYHaJ5GVyx1PhhOJ0Q@mail.gmail...
So I agree that your patch is adapted, even postgresql.conf.sample
gets that right. Something that your patch makes worse is the
alphabetical order of the parameters listed in this section
(backend_flush_after can be also blamed here), so I'll go reorder this
sub-area a bit while on it, except if somebody objects.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #16972: parameter parallel_leader_participation's category problem
@ 2021-04-21 03:45 Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 10+ messages in thread
From: Bharath Rupireddy @ 2021-04-21 03:45 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: leiyanliang@highgo.com; pgsql-bugs@lists.postgresql.org
On Wed, Apr 21, 2021 at 8:16 AM Michael Paquier <michael@paquier.xyz> wrote:
> So I agree that your patch is adapted, even postgresql.conf.sample
> gets that right. Something that your patch makes worse is the
> alphabetical order of the parameters listed in this section
> (backend_flush_after can be also blamed here), so I'll go reorder this
> sub-area a bit while on it, except if somebody objects.
If we arrange only the "Asynchronous Behaviour" subsection in
alphabetical order, I think the order may not be maintained in case of
new GUCs that may get added there. Because all the other subsections
are unordered and there's no note of maintaining the order as such.
And, it looks like the relevant GUCs are grouped for better
readability. For instance, all "parallelism", "io_concurrency", "jit_"
related GUCs are together. Developers tend to add the new GUCs in
relevant areas.
So, -1 for reordering.
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #16972: parameter parallel_leader_participation's category problem
@ 2021-04-21 10:44 Michael Paquier <michael@paquier.xyz>
parent: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: Michael Paquier @ 2021-04-21 10:44 UTC (permalink / raw)
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>; +Cc: leiyanliang@highgo.com; pgsql-bugs@lists.postgresql.org
On Wed, Apr 21, 2021 at 09:15:23AM +0530, Bharath Rupireddy wrote:
> If we arrange only the "Asynchronous Behaviour" subsection in
> alphabetical order, I think the order may not be maintained in case of
> new GUCs that may get added there. Because all the other subsections
> are unordered and there's no note of maintaining the order as such.
> And, it looks like the relevant GUCs are grouped for better
> readability. For instance, all "parallelism", "io_concurrency", "jit_"
> related GUCs are together. Developers tend to add the new GUCs in
> relevant areas.
That's up to the committers adding them to be careful, but I of course
agree that the context is important. IMV, we can do a slightly better
organization in "Asynchronous Behaviour". First, backend_flush_after
is independent, and could just be first.
parallel_leader_participation can also be moved after
max_parallel_workers without impacting the readability nor impacting
the set of parallel-ish parameters grouped together.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #16972: parameter parallel_leader_participation's category problem
@ 2021-04-21 11:37 Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 10+ messages in thread
From: Bharath Rupireddy @ 2021-04-21 11:37 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: leiyanliang@highgo.com; pgsql-bugs@lists.postgresql.org
On Wed, Apr 21, 2021 at 4:15 PM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Wed, Apr 21, 2021 at 09:15:23AM +0530, Bharath Rupireddy wrote:
> > If we arrange only the "Asynchronous Behaviour" subsection in
> > alphabetical order, I think the order may not be maintained in case of
> > new GUCs that may get added there. Because all the other subsections
> > are unordered and there's no note of maintaining the order as such.
> > And, it looks like the relevant GUCs are grouped for better
> > readability. For instance, all "parallelism", "io_concurrency", "jit_"
> > related GUCs are together. Developers tend to add the new GUCs in
> > relevant areas.
>
> That's up to the committers adding them to be careful, but I of course
> agree that the context is important. IMV, we can do a slightly better
> organization in "Asynchronous Behaviour". First, backend_flush_after
> is independent, and could just be first.
>
> parallel_leader_participation can also be moved after
> max_parallel_workers without impacting the readability nor impacting
> the set of parallel-ish parameters grouped together.
+1. Attached v2.
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
Attachments:
v2-0001-Move-parallel_leader_participation-to-Resource-Co.patch (application/octet-stream, 7.1K) download
From 2df2e69d5c7a6bba06e741a95e944a83fc21ab60 Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy <bharath.rupireddy@enterprisedb.com>
Date: Wed, 21 Apr 2021 16:58:48 +0530
Subject: [PATCH v2] Move parallel_leader_participation to Resource Consumption
Category
parallel_leader_partiticipation GUC is rightly categorized as
Resource Usage/Asynchronous Behavior parameter in the code by
the commit e5253fd, but in the docs, it is still under
Query Planning/Other Planner Options category. Just move it to
the correct place i.e. under Resource Consumption/
Asynchronous Behaviour category.
While on this, backend_flush_after GUC is moved to first from
last in the list under Asynchronous Behaviour section. This looks
slightly better organized.
---
doc/src/sgml/config.sgml | 88 ++++++++++++++++++++--------------------
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index dd7ebe7a9d..5d86b815de 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2382,6 +2382,36 @@ include_dir 'conf.d'
<sect2 id="runtime-config-resource-async-behavior">
<title>Asynchronous Behavior</title>
+ <varlistentry id="guc-backend-flush-after" xreflabel="backend_flush_after">
+ <term><varname>backend_flush_after</varname> (<type>integer</type>)
+ <indexterm>
+ <primary><varname>backend_flush_after</varname> configuration parameter</primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ Whenever more than this amount of data has
+ been written by a single backend, attempt to force the OS to issue
+ these writes to the underlying storage. Doing so will limit the
+ amount of dirty data in the kernel's page cache, reducing the
+ likelihood of stalls when an <function>fsync</function> is issued at the end of a
+ checkpoint, or when the OS writes data back in larger batches in the
+ background. Often that will result in greatly reduced transaction
+ latency, but there also are some cases, especially with workloads
+ that are bigger than <xref linkend="guc-shared-buffers"/>, but smaller
+ than the OS's page cache, where performance might degrade. This
+ setting may have no effect on some platforms.
+ If this value is specified without units, it is taken as blocks,
+ that is <symbol>BLCKSZ</symbol> bytes, typically 8kB.
+ The valid range is
+ between <literal>0</literal>, which disables forced writeback,
+ and <literal>2MB</literal>. The default is <literal>0</literal>, i.e., no
+ forced writeback. (If <symbol>BLCKSZ</symbol> is not 8kB,
+ the maximum value scales proportionally to it.)
+ </para>
+ </listitem>
+ </varlistentry>
+
<variablelist>
<varlistentry id="guc-effective-io-concurrency" xreflabel="effective_io_concurrency">
<term><varname>effective_io_concurrency</varname> (<type>integer</type>)
@@ -2579,32 +2609,25 @@ include_dir 'conf.d'
</listitem>
</varlistentry>
- <varlistentry id="guc-backend-flush-after" xreflabel="backend_flush_after">
- <term><varname>backend_flush_after</varname> (<type>integer</type>)
+ <varlistentry id="guc-parallel-leader-participation" xreflabel="parallel_leader_participation">
+ <term>
+ <varname>parallel_leader_participation</varname> (<type>boolean</type>)
<indexterm>
- <primary><varname>backend_flush_after</varname> configuration parameter</primary>
+ <primary><varname>parallel_leader_participation</varname> configuration parameter</primary>
</indexterm>
</term>
<listitem>
<para>
- Whenever more than this amount of data has
- been written by a single backend, attempt to force the OS to issue
- these writes to the underlying storage. Doing so will limit the
- amount of dirty data in the kernel's page cache, reducing the
- likelihood of stalls when an <function>fsync</function> is issued at the end of a
- checkpoint, or when the OS writes data back in larger batches in the
- background. Often that will result in greatly reduced transaction
- latency, but there also are some cases, especially with workloads
- that are bigger than <xref linkend="guc-shared-buffers"/>, but smaller
- than the OS's page cache, where performance might degrade. This
- setting may have no effect on some platforms.
- If this value is specified without units, it is taken as blocks,
- that is <symbol>BLCKSZ</symbol> bytes, typically 8kB.
- The valid range is
- between <literal>0</literal>, which disables forced writeback,
- and <literal>2MB</literal>. The default is <literal>0</literal>, i.e., no
- forced writeback. (If <symbol>BLCKSZ</symbol> is not 8kB,
- the maximum value scales proportionally to it.)
+ Allows the leader process to execute the query plan under
+ <literal>Gather</literal> and <literal>Gather Merge</literal> nodes
+ instead of waiting for worker processes. The default is
+ <literal>on</literal>. Setting this value to <literal>off</literal>
+ reduces the likelihood that workers will become blocked because the
+ leader is not reading tuples fast enough, but requires the leader
+ process to wait for worker processes to start up before the first
+ tuples can be produced. The degree to which the leader can help or
+ hinder performance depends on the plan type, number of workers and
+ query duration.
</para>
</listitem>
</varlistentry>
@@ -5889,29 +5912,6 @@ SELECT * FROM parent WHERE key = 2400;
</listitem>
</varlistentry>
- <varlistentry id="guc-parallel-leader-participation" xreflabel="parallel_leader_participation">
- <term>
- <varname>parallel_leader_participation</varname> (<type>boolean</type>)
- <indexterm>
- <primary><varname>parallel_leader_participation</varname> configuration parameter</primary>
- </indexterm>
- </term>
- <listitem>
- <para>
- Allows the leader process to execute the query plan under
- <literal>Gather</literal> and <literal>Gather Merge</literal> nodes
- instead of waiting for worker processes. The default is
- <literal>on</literal>. Setting this value to <literal>off</literal>
- reduces the likelihood that workers will become blocked because the
- leader is not reading tuples fast enough, but requires the leader
- process to wait for worker processes to start up before the first
- tuples can be produced. The degree to which the leader can help or
- hinder performance depends on the plan type, number of workers and
- query duration.
- </para>
- </listitem>
- </varlistentry>
-
<varlistentry id="guc-plan-cache_mode" xreflabel="plan_cache_mode">
<term><varname>plan_cache_mode</varname> (<type>enum</type>)
<indexterm>
--
2.25.1
* Re: BUG #16972: parameter parallel_leader_participation's category problem
@ 2021-04-22 00:57 Michael Paquier <michael@paquier.xyz>
parent: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: Michael Paquier @ 2021-04-22 00:57 UTC (permalink / raw)
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>; +Cc: leiyanliang@highgo.com; pgsql-bugs@lists.postgresql.org
On Wed, Apr 21, 2021 at 05:07:37PM +0530, Bharath Rupireddy wrote:
> +1. Attached v2.
This patch broke the compilation of the docs as you moved the
<varlistentry> for backend_flush_after before <variablelist>. Fixed
that, then applied the patch.
Thanks,
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #16972: parameter parallel_leader_participation's category problem
@ 2021-04-22 01:02 Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 10+ messages in thread
From: Bharath Rupireddy @ 2021-04-22 01:02 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: leiyanliang@highgo.com; pgsql-bugs@lists.postgresql.org
Thanks for the correction! I never compiled doc changes, I will ensure to
do so from now on.
Regards,
Bharath Rupireddy.
On Thu, Apr 22, 2021, 6:27 AM Michael Paquier <michael@paquier.xyz> wrote:
> On Wed, Apr 21, 2021 at 05:07:37PM +0530, Bharath Rupireddy wrote:
> > +1. Attached v2.
>
> This patch broke the compilation of the docs as you moved the
> <varlistentry> for backend_flush_after before <variablelist>. Fixed
> that, then applied the patch.
>
> Thanks,
> --
> Michael
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #16972: parameter parallel_leader_participation's category problem
@ 2021-04-22 05:00 Michael Paquier <michael@paquier.xyz>
parent: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: Michael Paquier @ 2021-04-22 05:00 UTC (permalink / raw)
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>; +Cc: leiyanliang@highgo.com; pgsql-bugs@lists.postgresql.org
On Thu, Apr 22, 2021 at 06:32:57AM +0530, Bharath Rupireddy wrote:
> Thanks for the correction! I never compiled doc changes, I will ensure to
> do so from now on.
That may help:
https://www.postgresql.org/docs/devel/docguide-toolsets.html
It is worth noting that when doing patches for stable branches, the
set of dependencies for ~10 is different than what's used for
11~HEAD.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #16972: parameter parallel_leader_participation's category problem
@ 2021-04-22 05:04 Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 0 replies; 10+ messages in thread
From: Bharath Rupireddy @ 2021-04-22 05:04 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: leiyanliang@highgo.com; pgsql-bugs@lists.postgresql.org
On Thu, Apr 22, 2021 at 10:30 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Thu, Apr 22, 2021 at 06:32:57AM +0530, Bharath Rupireddy wrote:
> > Thanks for the correction! I never compiled doc changes, I will ensure to
> > do so from now on.
>
> That may help:
> https://www.postgresql.org/docs/devel/docguide-toolsets.html
Thanks. I was able to install the required packages on my dev system,
ran "make check" on the docs and saw the error that was happening on
v2 patch.
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2021-04-22 05:04 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-04-20 06:45 BUG #16972: parameter parallel_leader_participation's category problem PG Bug reporting form <noreply@postgresql.org>
2021-04-20 08:08 ` Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
2021-04-21 02:46 ` Michael Paquier <michael@paquier.xyz>
2021-04-21 03:45 ` Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
2021-04-21 10:44 ` Michael Paquier <michael@paquier.xyz>
2021-04-21 11:37 ` Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
2021-04-22 00:57 ` Michael Paquier <michael@paquier.xyz>
2021-04-22 01:02 ` Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
2021-04-22 05:00 ` Michael Paquier <michael@paquier.xyz>
2021-04-22 05:04 ` Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox