correction

2022-05-11 Thread PG Doc comments form
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/14/transaction-iso.html Description: in this page: https://www.postgresql.org/docs/14/transaction-iso.html under the Table 13.1 section, if we search for "phantom reads. Stricter behavior is

Correction

2022-07-24 Thread PG Doc comments form
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/14/citext.html Description: "If you declare a column as UNIQUE or PRIMARY KEY, the implicitly generated index is case-sensitive. So it's useless for case-insensitive searches, and it won't en

Manua correction

2021-07-13 Thread PG Doc comments form
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/functions-string.html Description: Hopefully the referrer page was kept. I'm referring to the string functions page that reads... == position ( substring text IN string text ) → integer R

Re: correction

2022-05-11 Thread Laurenz Albe
On Wed, 2022-05-11 at 00:33 +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/14/transaction-iso.html > Description: > > in this page: https://www.postgresql.org/docs/14/transaction-iso.html > > unde

Re: correction

2022-05-13 Thread Bruce Momjian
On Wed, May 11, 2022 at 12:36:11PM +0200, Laurenz Albe wrote: > On Wed, 2022-05-11 at 00:33 +, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/14/transaction-iso.html > > Description: > > > > in

Re: correction

2022-05-13 Thread Laurenz Albe
On Fri, 2022-05-13 at 16:36 -0400, Bruce Momjian wrote: > On Wed, May 11, 2022 at 12:36:11PM +0200, Laurenz Albe wrote: > > On Wed, 2022-05-11 at 00:33 +, PG Doc comments form wrote: > > > The following documentation comment has been logged on the website: > > > > > > Page: https://www.postgre

Re: correction

2022-05-13 Thread David G. Johnston
On Fri, May 13, 2022 at 2:49 PM Laurenz Albe wrote: > On Fri, 2022-05-13 at 16:36 -0400, Bruce Momjian wrote: > > On Wed, May 11, 2022 at 12:36:11PM +0200, Laurenz Albe wrote: > > > On Wed, 2022-05-11 at 00:33 +, PG Doc comments form wrote: > > > > The following documentation comment has been

Re: correction

2022-06-07 Thread Bruce Momjian
On Fri, May 13, 2022 at 11:49:09PM +0200, Laurenz Albe wrote: > I think that suffers from the same problem: izt sounds like the standard > allows > stricter behavior than PostgreSQL. > > How about: > > The table also shows that PostgreSQL's Repeatable Read implementation > does not allow pha

Re: correction

2022-06-07 Thread David G. Johnston
On Tue, Jun 7, 2022 at 2:07 PM Bruce Momjian wrote: > > > How is this, attached? > > Works for me. Capital "S" in Standard as a proper name? (mind grepping this to see how consistent we are one way or the other, I'm not setup for that at the moment) David J.

Re: correction

2022-06-07 Thread Bruce Momjian
On Tue, Jun 7, 2022 at 02:40:41PM -0700, David G. Johnston wrote: > On Tue, Jun 7, 2022 at 2:07 PM Bruce Momjian wrote: > > > > How is this, attached? > > > > Works for me. > > Capital "S" in Standard as a proper name? (mind grepping this to see how > consistent we are one way or the o

Re: correction

2022-06-07 Thread David G. Johnston
On Tue, Jun 7, 2022 at 4:51 PM Bruce Momjian wrote: > On Tue, Jun 7, 2022 at 02:40:41PM -0700, David G. Johnston wrote: > > On Tue, Jun 7, 2022 at 2:07 PM Bruce Momjian wrote: > > > > > > > > How is this, attached? > > > > > > > > Works for me. > > > > Capital "S" in Standard as a proper na

Re: correction

2022-06-07 Thread Tom Lane
Bruce Momjian writes: > +not occur at certain isolation levels; higher The docs toolchain is not gonna like that. regards, tom lane

Re: correction

2022-06-07 Thread Bruce Momjian
On Tue, Jun 7, 2022 at 08:00:16PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > +not occur at certain isolation levels; higher > > The docs toolchain is not gonna like that. You are correct. I should have tested, updated patch attached. -- Bruce Momjian https://momjian.u

Re: correction

2022-06-09 Thread David G. Johnston
On Tue, Jun 7, 2022 at 5:26 PM Bruce Momjian wrote: > On Tue, Jun 7, 2022 at 08:00:16PM -0400, Tom Lane wrote: > > Bruce Momjian writes: > > > +not occur at certain isolation levels; > higher > > > > The docs toolchain is not gonna like that. > > You are correct. I should have tested, upda

Re: correction

2022-06-22 Thread Bruce Momjian
On Tue, Jun 7, 2022 at 07:51:20PM -0400, Bruce Momjian wrote: > On Tue, Jun 7, 2022 at 02:40:41PM -0700, David G. Johnston wrote: > > On Tue, Jun 7, 2022 at 2:07 PM Bruce Momjian wrote: > > > > > > > > How is this, attached? > > > > > > > > Works for me. > > > > Capital "S" in Standar

Re: Correction

2022-07-24 Thread Tom Lane
PG Doc comments form writes: > "If you declare a column as UNIQUE or PRIMARY KEY, the implicitly generated > index is case-sensitive. So it's useless for case-insensitive searches, and > it won't enforce uniqueness case-insensitively." > I think the statement above is not correct. I tried creatin

doc correction

2019-10-29 Thread PG Doc comments form
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/ddl-generated-columns.html Description: https://www.postgresql.org/docs/12/ddl-generated-columns.html In the below "Consider the differences between a column with a default and a generate

Re: Manua correction

2021-07-15 Thread Bruce Momjian
On Tue, Jul 13, 2021 at 02:24:01AM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/13/functions-string.html > Description: > > Hopefully the referrer page was kept. I'm referring to the string funct

Re: Manua correction

2021-07-15 Thread Tom Lane
Bruce Momjian writes: > Interesting. I see several cases where our docs are not clear we > process only the first match: At least two of these changes are flat out wrong. The places that explicitly mention "substring(s)" are not doing so because we failed to think about what that meant.

Re: Manua correction

2021-07-19 Thread Bruce Momjian
On Thu, Jul 15, 2021 at 11:12:38PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > Interesting. I see several cases where our docs are not clear we > > process only the first match: > > At least two of these changes are flat out wrong. The places > that explicitly mention "substring(s)" are

Re: Manua correction

2021-07-20 Thread Tom Lane
Bruce Momjian writes: > On Thu, Jul 15, 2021 at 11:12:38PM -0400, Tom Lane wrote: >> At least two of these changes are flat out wrong. The places >> that explicitly mention "substring(s)" are not doing so because >> we failed to think about what that meant. > I really don't understand the use of

Re: Manua correction

2021-07-20 Thread Bruce Momjian
On Tue, Jul 20, 2021 at 11:03:09AM -0400, Tom Lane wrote: > Bruce Momjian writes: > > I really don't understand the use of "(s)" except in place where we are > > really trying to point out the idea of one or multiple, and I don't see > > that being significant in these cases --- can you clarify? >

Re: Manua correction

2021-07-26 Thread Bruce Momjian
On Tue, Jul 20, 2021 at 04:06:17PM -0400, Bruce Momjian wrote: > On Tue, Jul 20, 2021 at 11:03:09AM -0400, Tom Lane wrote: > > The places where you changed "substring(s)" to "substrings" are maybe > > not flat wrong, but I don't think they're improving the text either. > > IIRC, in most of them you

Correction for vacuum_multixact_failsafe_age

2021-10-11 Thread Pavel Luzanov
Hello, When trying to make a link to the new vacuum_multixact_failsafe_age parameter, I found the wrong ID for this guc (missed word vacuum). Please consider this patch for a fix. -- Pavel Luzanov Postgres Professional: https://postgrespro.com The Russian Postgres Company diff --git a/doc/src/s

Re: [DOCS] Correction

2017-11-21 Thread Gokhan Demir
Hi Tom, Then I guess I will need to read that part of the chapter again. Many thanks for the clarification. Gokhan. On Mon, Nov 20, 2017 at 12:17 AM, Tom Lane wrote: > demirgok...@gmail.com writes: > > The following documentation comment has been logged on the website: > > Page: https://www.po

"DROP INDEX" correction

2019-10-02 Thread Oto Brglez
Hello people! I'm new to this place and this is obviously my first message to you guys. I've been using PostgreSQL for years now, deeply like it and I came to a point when I wish to give some of this love back. :) So; I'm reaching out this mailing list - hopefully the right one - because we foun

Re: doc correction

2019-10-29 Thread Peter Eisentraut
On 2019-10-28 23:41, PG Doc comments form wrote: The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/ddl-generated-columns.html Description: https://www.postgresql.org/docs/12/ddl-generated-columns.html In the below "Consider the differe

Re: Correction for vacuum_multixact_failsafe_age

2021-10-11 Thread Laurenz Albe
On Tue, 2021-10-12 at 08:22 +0300, Pavel Luzanov wrote: > When trying to make a link to the new vacuum_multixact_failsafe_age parameter, > I found the wrong ID for this guc (missed word vacuum). > Please consider this patch for a fix. It is good to be consistent, but the name of the link is not es

Re: Correction for vacuum_multixact_failsafe_age

2021-10-12 Thread Pavel Luzanov
Hello, When trying to make a link to the new vacuum_multixact_failsafe_age parameter, I found the wrong ID for this guc (missed word vacuum). Please consider this patch for a fix. It is good to be consistent, but the name of the link is not essential, is it? Changing it might break existing out

Re: Correction for vacuum_multixact_failsafe_age

2021-10-12 Thread Alvaro Herrera
On 2021-Oct-12, Pavel Luzanov wrote: > Hello, > > > > When trying to make a link to the new vacuum_multixact_failsafe_age > > > parameter, > > > I found the wrong ID for this guc (missed word vacuum). > > > Please consider this patch for a fix. > > It is good to be consistent, but the name of th

Re: Correction for vacuum_multixact_failsafe_age

2021-10-12 Thread Peter Geoghegan
On Tue, Oct 12, 2021 at 10:46 AM Alvaro Herrera wrote: > Yeah, this one is new as of commit 1e55e7d1755c; ISTM we should just fix it. Agreed. Pushed Pavel's patch just now. Thanks -- Peter Geoghegan

Re: Correction for vacuum_multixact_failsafe_age

2021-10-28 Thread Pavel Luzanov
Hi, Agreed. Pushed Pavel's patch just now. Sorry, I didn't check it right away. But it makes sense to backport to v14, where vacuum_multixact_failsafe_age was introduced. -- Pavel Luzanov Postgres Professional: https://postgrespro.com The Russian Postgres Company

Re: Correction for vacuum_multixact_failsafe_age

2021-10-28 Thread Alvaro Herrera
On 2021-Oct-28, Pavel Luzanov wrote: > Hi, > > > Agreed. Pushed Pavel's patch just now. > > Sorry, I didn't check it right away. > But it makes sense to backport to v14, where vacuum_multixact_failsafe_age > was introduced. It is in 14. Author: Peter Geoghegan Branch: master [00c61a74b] 2021

Re: Correction for vacuum_multixact_failsafe_age

2021-10-28 Thread Peter Geoghegan
On Thu, Oct 28, 2021 at 1:58 PM Alvaro Herrera wrote: > It is in 14. Right. It won't be reflected on the website until 14.1 is released, though. -- Peter Geoghegan

Re: Correction for vacuum_multixact_failsafe_age

2021-10-28 Thread Pavel Luzanov
Hi, It won't be reflected on the website until 14.1 is released, though. Thank you! I had completely forgotten about that and looking for changes on the website. -- Pavel Luzanov Postgres Professional: https://postgrespro.com The Russian Postgres Company

AT TIME ZONE correction

2018-09-01 Thread Bruce Momjian
Looking over the AT TIME ZONE docs, I think they are subtly confusing. The order of conversion specific in the first example should _start_ with the assumption of local time zone for the time stamp, not something that happens after AT TIME ZONE is applied. The ordering in current docs makes the s

Re: "DROP INDEX" correction

2019-10-02 Thread Michael Paquier
Hi Oto, On Wed, Oct 02, 2019 at 09:55:14AM +0200, Oto Brglez wrote: > I suggest that you add a statement/explanation under Parameters > > CONCURRENTLY that would say something like > > "DROP INDEX with CONCURRENTLY can only accept one index." > > I hope that this message will be helpful to someo

Correction For PostgreSQL Manual

2019-10-25 Thread PG Doc comments form
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/bgworker.html Description: The warning about background worker processes at the beginning of Chapter 47 reads: Administrators wishing to enable modules that include background worker proc

Correction of intermediate certificate handling

2018-01-15 Thread Bruce Momjian
We have been confused by the behavior of intermediate certificates in Postgres for many years. Some people put the intermediate certificates only on the server and they were supplied to the client, while other people couldn't get that to work. In our documentation we recommended storing intermedi

Re: AT TIME ZONE correction

2018-09-01 Thread Tom Lane
Bruce Momjian writes: > Looking over the AT TIME ZONE docs, I think they are subtly confusing. > The order of conversion specific in the first example should _start_ > with the assumption of local time zone for the time stamp, not something > that happens after AT TIME ZONE is applied. The order

Re: AT TIME ZONE correction

2018-09-01 Thread Bruce Momjian
On Sat, Sep 1, 2018 at 07:30:43PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > Looking over the AT TIME ZONE docs, I think they are subtly confusing. > > The order of conversion specific in the first example should _start_ > > with the assumption of local time zone for the time stamp, not

Re: AT TIME ZONE correction

2018-09-01 Thread Bruce Momjian
On Sat, Sep 1, 2018 at 07:37:36PM -0400, Bruce Momjian wrote: > > Here we've got a time value that was initially given in EST (-05), > > but was converted to UTC by timestampz_in. Then the AT TIME ZONE > > says "Please convert this UTC value to MST, and emit it as a zoneless > > timestamp" (which

Re: AT TIME ZONE correction

2018-09-02 Thread Tom Lane
Bruce Momjian writes: > ! The AT TIME ZONE construct allows the addition, > ! conversion, and removal of time zones for time stamp values. linkend="functions-datetime-zoneconvert-table"/> shows its > variants. Maybe it'd be more to the point to say that it allows conversion

Re: AT TIME ZONE correction

2018-09-02 Thread Bruce Momjian
fOn Sun, Sep 2, 2018 at 02:21:58PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > ! The AT TIME ZONE construct allows the addition, > > ! conversion, and removal of time zones for time stamp values. > linkend="functions-datetime-zoneconvert-table"/> shows its > > variant

Re: AT TIME ZONE correction

2018-09-03 Thread Bruce Momjian
On Sun, Sep 2, 2018 at 10:11:59PM -0400, Bruce Momjian wrote: > On Sun, Sep 2, 2018 at 02:21:58PM -0400, Tom Lane wrote: > > I still find this to be more confusing than helpful. In particular, > > I do not think that it's possible to explain this behavior clearly > > without mentioning that time

Re: AT TIME ZONE correction

2018-09-04 Thread Bruce Momjian
On Mon, Sep 3, 2018 at 09:20:34AM -0400, Bruce Momjian wrote: > On Sun, Sep 2, 2018 at 10:11:59PM -0400, Bruce Momjian wrote: > > On Sun, Sep 2, 2018 at 02:21:58PM -0400, Tom Lane wrote: > > > I still find this to be more confusing than helpful. In particular, > > > I do not think that it's pos

Re: Correction For PostgreSQL Manual

2019-11-05 Thread Bruce Momjian
On Fri, Oct 25, 2019 at 09:56:47PM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/12/bgworker.html > Description: > > The warning about background worker processes at the beginning of Chapter 47 >

Re: Correction For PostgreSQL Manual

2019-11-05 Thread Justin Pryzby
On Tue, Nov 05, 2019 at 08:54:46PM -0500, Bruce Momjian wrote: > On Fri, Oct 25, 2019 at 09:56:47PM +, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/12/bgworker.html > > Description: > > > > Th

Re: Correction For PostgreSQL Manual

2019-11-05 Thread Bruce Momjian
89ae5a31b86fa => bad: processs > 2a4d96e..a386942 master -> origin/master > 4b5e58b86e3b09daa7384dbbd0bb4cacbd9bd7c6 => ok Thank you so much for the correction, fixed. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +

Re: Correction of intermediate certificate handling

2018-01-15 Thread Michael Paquier
On Mon, Jan 15, 2018 at 07:22:38PM -0500, Bruce Momjian wrote: > I asked Stephen Frost and David Steele for details on the arcane art of > SSL certificate creation. They showed me scripts they use and explained > that they properly pass intermediate certificates to clients. The trick > was to use

Re: Correction of intermediate certificate handling

2018-01-16 Thread Bruce Momjian
On Tue, Jan 16, 2018 at 02:33:05PM +0900, Michael Paquier wrote: > > My talk documents this behavior. In this talk: > > > > https://momjian.us/main/writings/pgsql/tls.pdf > > > > slide 47 and 49 use -extensions v3_ca. Slides 73 and 74 show that the > > intermediate is not needed on the clie

Re: Correction of intermediate certificate handling

2018-01-16 Thread Michael Paquier
On Tue, Jan 16, 2018 at 11:21:22AM -0500, Bruce Momjian wrote: > On Tue, Jan 16, 2018 at 02:33:05PM +0900, Michael Paquier wrote: > > This bit is important. I am happy that your patch mentions that > > intermediate certificates avoid the need to store root ones on the > > client. Should the docs me

Re: Correction of intermediate certificate handling

2018-01-16 Thread Bruce Momjian
On Wed, Jan 17, 2018 at 09:09:50AM +0900, Michael Paquier wrote: > On Tue, Jan 16, 2018 at 11:21:22AM -0500, Bruce Momjian wrote: > > On Tue, Jan 16, 2018 at 02:33:05PM +0900, Michael Paquier wrote: > > > This bit is important. I am happy that your patch mentions that > > > intermediate certificate

Re: Correction of intermediate certificate handling

2018-01-17 Thread Michael Paquier
On Tue, Jan 16, 2018 at 10:23:44PM -0500, Bruce Momjian wrote: > On Wed, Jan 17, 2018 at 09:09:50AM +0900, Michael Paquier wrote: > > On Tue, Jan 16, 2018 at 11:21:22AM -0500, Bruce Momjian wrote: > > > On Tue, Jan 16, 2018 at 02:33:05PM +0900, Michael Paquier wrote: > > I ended up merging the "ch

Re: Correction of intermediate certificate handling

2018-01-17 Thread Bruce Momjian
On Wed, Jan 17, 2018 at 05:20:00PM +0900, Michael Paquier wrote: > On Tue, Jan 16, 2018 at 10:23:44PM -0500, Bruce Momjian wrote: > > On Wed, Jan 17, 2018 at 09:09:50AM +0900, Michael Paquier wrote: > > > On Tue, Jan 16, 2018 at 11:21:22AM -0500, Bruce Momjian wrote: > > > > On Tue, Jan 16, 2018 at

Re: Correction of intermediate certificate handling

2018-01-17 Thread Bruce Momjian
On Wed, Jan 17, 2018 at 07:34:42AM -0500, Bruce Momjian wrote: > > The succession of commands of commands for the intermediate certificates > > is wild. Could it be possible to explain what each command means? Users > > would not get lost this way. > > Yes, I was not happy about that either. I wa

Re: Correction of intermediate certificate handling

2018-01-17 Thread Michael Paquier
On Wed, Jan 17, 2018 at 08:39:55AM -0500, Bruce Momjian wrote: > On Wed, Jan 17, 2018 at 07:34:42AM -0500, Bruce Momjian wrote: > > > The succession of commands of commands for the intermediate certificates > > > is wild. Could it be possible to explain what each command means? Users > > > would no

Re: Correction of intermediate certificate handling

2018-01-17 Thread Michael Paquier
On Wed, Jan 17, 2018 at 07:34:42AM -0500, Bruce Momjian wrote: > On Wed, Jan 17, 2018 at 05:20:00PM +0900, Michael Paquier wrote: > > The succession of commands of commands for the intermediate certificates > > is wild. Could it be possible to explain what each command means? Users > > would not ge

Re: Correction of intermediate certificate handling

2018-01-17 Thread Bruce Momjian
On Thu, Jan 18, 2018 at 10:25:03AM +0900, Michael Paquier wrote: > On Wed, Jan 17, 2018 at 07:34:42AM -0500, Bruce Momjian wrote: > > Yes, I was not happy about that either. I was afraid that pound-sign > > comments would look like root prompts but I just added them and they > > look fine. Update

Re: Correction of intermediate certificate handling

2018-01-17 Thread Michael Paquier
On Wed, Jan 17, 2018 at 09:00:17PM -0500, Bruce Momjian wrote: > On Thu, Jan 18, 2018 at 10:25:03AM +0900, Michael Paquier wrote: > > /etc/ssl/openssl.cnf is not available on macos or Windows, which can > > lead to a bit of confusion as I would imagine that people would > > copy/paste such commands

Re: Correction of intermediate certificate handling

2018-01-20 Thread Bruce Momjian
On Thu, Jan 18, 2018 at 12:17:40PM +0900, Michael Paquier wrote: > On Wed, Jan 17, 2018 at 09:00:17PM -0500, Bruce Momjian wrote: > > On Thu, Jan 18, 2018 at 10:25:03AM +0900, Michael Paquier wrote: > > > /etc/ssl/openssl.cnf is not available on macos or Windows, which can > > > lead to a bit of co

Re: Correction of intermediate certificate handling

2018-01-25 Thread Peter Eisentraut
On 1/16/18 00:33, Michael Paquier wrote: > On top of that, src/test/ssl does not provide any kind of coverage for > that. It would be an area of improvement for those tests. The tests already cover this: # intermediate client_ca.crt is provided by client, and isn't in server's ssl_ca_file switch_

Re: Correction of intermediate certificate handling

2018-01-26 Thread Bruce Momjian
On Thu, Jan 25, 2018 at 10:59:23PM -0500, Peter Eisentraut wrote: > On 1/16/18 00:33, Michael Paquier wrote: > > On top of that, src/test/ssl does not provide any kind of coverage for > > that. It would be an area of improvement for those tests. > > The tests already cover this: > > # intermediat

Re: Correction of intermediate certificate handling

2018-01-26 Thread Michael Paquier
On Fri, Jan 26, 2018 at 08:09:30AM -0500, Bruce Momjian wrote: > On Thu, Jan 25, 2018 at 10:59:23PM -0500, Peter Eisentraut wrote: > > If you change the Makefile rule for generating the client CA to omit the > > -extensions v3_ca option, then the first test will fail. > > Oh, very good! Good poin

Correction for 9.6 documentation for OpenBSD

2018-04-02 Thread PG Doc comments form
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/9.6/static/server-start.html Description: OpenBSD 6.1 i386 PostgreSQL 9.6 In Section 18.3. Starting the Database Server, I did something different from the documentation. Instead of editing

11.7 Indexes on Expressions: editorial correction

2020-05-19 Thread PG Doc comments form
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/indexes-expressional.html Description: The paragraph that begins "If we were to declare this index UNIQUE,..." refers to the index test1_lower_col1_idx, not to the test1_uniq_int index it

Correction in doc of failover ready steps

2024-07-21 Thread shveta malik
v1-0001-Correction-in-doc-of-failover-ready-steps.patch Description: Binary data

Re: Correction for 9.6 documentation for OpenBSD

2018-06-29 Thread Daniel Gustafsson
> On 3 Apr 2018, at 07:29, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/9.6/static/server-start.html > Description: > > OpenBSD 6.1 i386 > PostgreSQL 9.6 > > In Section 18.3. Starting the Database

Re: Correction for 9.6 documentation for OpenBSD

2018-07-15 Thread Peter Eisentraut
On 29.06.18 22:57, Daniel Gustafsson wrote: > That being said, since the ports tree is the “recommended” method for > installing software perhaps the documentation should mention it? Perhaps > something along the lines of the below (a similar stanza could be added for > FreeBSD but I don’t it well

Re: 11.7 Indexes on Expressions: editorial correction

2020-05-19 Thread Tom Lane
PG Doc comments form writes: > The paragraph that begins "If we were to declare this index UNIQUE,..." > refers to the index test1_lower_col1_idx, not to the test1_uniq_int index it > currently follows. It would appear the latter example was spliced into the > middle of discussing the former. Yes

Re: 11.7 Indexes on Expressions: editorial correction

2020-05-21 Thread Bruce Momjian
On Tue, May 19, 2020 at 10:32:01AM -0400, Tom Lane wrote: > PG Doc comments form writes: > > The paragraph that begins "If we were to declare this index UNIQUE,..." > > refers to the index test1_lower_col1_idx, not to the test1_uniq_int index it > > currently follows. It would appear the latter ex

Re: Correction in doc of failover ready steps

2024-07-21 Thread shveta malik
On Mon, Jul 22, 2024 at 10:46 AM shveta malik wrote: > > Hi, > > We have a query in failover-ready doc referring to > pg_subscription_rel. Unlike pg_subscription, pg_subscription_rel gives > results only when connected to the database having the > subscription(s). If we run the concerned query on

Re: Correction in doc of failover ready steps

2024-07-22 Thread Amit Kapila
On Mon, Jul 22, 2024 at 10:59 AM shveta malik wrote: > > On Mon, Jul 22, 2024 at 10:46 AM shveta malik wrote: > > > > Hi, > > > > We have a query in failover-ready doc referring to > > pg_subscription_rel. Unlike pg_subscription, pg_subscription_rel gives > > results only when connected to the da

RE: Correction in doc of failover ready steps

2024-07-22 Thread Zhijie Hou (Fujitsu)
On Monday, July 22, 2024 7:13 PM Amit Kapila wrote: > > On Mon, Jul 22, 2024 at 10:59 AM shveta malik > wrote: > > > > On Mon, Jul 22, 2024 at 10:46 AM shveta malik > wrote: > > > > > > Hi, > > > > > > We have a query in failover-ready doc referring to > > > pg_subscription_rel. Unlike pg_subsc

Re: Correction in doc of failover ready steps

2024-07-22 Thread shveta malik
On Tue, Jul 23, 2024 at 8:14 AM Zhijie Hou (Fujitsu) wrote: > > I also agree that separating the 2 queries makes sense. Please find the patch with the suggested change. thanks Shveta v2-0001-Correction-in-doc-of-failover-ready-steps.patch Description: Binary data

Re: Correction in doc of failover ready steps

2024-07-23 Thread Amit Kapila
On Tue, Jul 23, 2024 at 9:40 AM shveta malik wrote: > > On Tue, Jul 23, 2024 at 8:14 AM Zhijie Hou (Fujitsu) > wrote: > > > > I also agree that separating the 2 queries makes sense. > > Please find the patch with the suggested change. > One minor comment: - if the table copy is finished (See

Re: Correction in doc of failover ready steps

2024-07-23 Thread shveta malik
hat it was introduced in the original commit but it seems better to > change if we agree. Yes, it makes sense. Please find the patch with this change. thanks SHveta v3-0001-Correction-in-doc-of-failover-ready-steps.patch Description: Binary data

RE: Correction in doc of failover ready steps

2024-07-23 Thread Zhijie Hou (Fujitsu)
On Wednesday, July 24, 2024 10:56 AM shveta malik wrote: > > On Tue, Jul 23, 2024 at 5:10 PM Amit Kapila wrote: > > > > One minor comment: > > - if the table copy is finished (See > linkend="catalog-pg-subscription-rel"/>). > > + On the subscriber node, use the following SQL to identif

Re: Correction in doc of failover ready steps

2024-07-23 Thread shveta malik
; is built by CONCAT() which means it should be valid, while the first query's > subslotname could be NULL if user executed ALTER SUB SET (slot_name = NONE). > Thanks for pointing it out. Please find a new patch with this change. Also corrected the commit message in this patch. thanks S

Correction to documentation at https://www.postgresql.org/docs/12/kernel-resources.html

2021-10-05 Thread PG Doc comments form
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/kernel-resources.html Description: Hi. On https://www.postgresql.org/docs/12/kernel-resources.html, the command to calculate memory allocated to postgres is not correct. Following is the

Re: Correction to documentation at https://www.postgresql.org/docs/12/kernel-resources.html

2021-10-05 Thread Tom Lane
PG Doc comments form writes: > On https://www.postgresql.org/docs/12/kernel-resources.html, the command to > calculate memory allocated to postgres is not correct. Following is the > command as shown in 18.4.5. Linux Huge Pages. > pmap 4170 | awk '/rw-s/ && /zero/ {print $2}', this command does no

Re: Correction to documentation at https://www.postgresql.org/docs/12/kernel-resources.html

2021-10-05 Thread Thomas Munro
On Wed, Oct 6, 2021 at 3:48 AM Tom Lane wrote: > PG Doc comments form writes: > > On https://www.postgresql.org/docs/12/kernel-resources.html, the command to > > calculate memory allocated to postgres is not correct. Following is the > > command as shown in 18.4.5. Linux Huge Pages. > > pmap 4170

Re: Correction to documentation at https://www.postgresql.org/docs/12/kernel-resources.html

2021-10-07 Thread Sanjeev Adwal
Thanks Thomas. Looks like I misread that. On Wednesday, 6 October, 2021, 04:56:42 am IST, Thomas Munro wrote: On Wed, Oct 6, 2021 at 3:48 AM Tom Lane wrote: > PG Doc comments form writes: > > On https://www.postgresql.org/docs/12/kernel-resources.html, the command to > > calculate mem

Minor correction in the doc for non-exclusive pg_start_backup and pg_stop_backup

2019-04-18 Thread Fujii Masao
Hi, > These functions cannot be executed during recovery (except > pg_is_in_backup, > pg_backup_start_time > and pg_wal_lsn_diff). Regarding backup control functions, the func.sgml describes as above. But non-exclusive pg_start_backup and pg_stop_backup can also be executed during re

Correction: Postgres emum documentation 8.7.4 should read 63 characters (instead of bytes)

2023-04-02 Thread PG Doc comments form
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/15/datatype-enum.html Description: Postgres documentation, section 8.7.4 gives the limit on enum labels as 63 bytes. Testing this with an oversized string gives the following error: SQL Error

Re: Minor correction in the doc for non-exclusive pg_start_backup and pg_stop_backup

2019-04-18 Thread Michael Paquier
On Fri, Apr 19, 2019 at 12:38:23AM +0900, Fujii Masao wrote: > Regarding backup control functions, the func.sgml describes as above. > But non-exclusive pg_start_backup and pg_stop_backup can also be > executed during recovery, and which should be described in the doc. > So I think that the attache

Re: Minor correction in the doc for non-exclusive pg_start_backup and pg_stop_backup

2019-04-22 Thread Fujii Masao
On Fri, Apr 19, 2019 at 11:36 AM Michael Paquier wrote: > > On Fri, Apr 19, 2019 at 12:38:23AM +0900, Fujii Masao wrote: > > Regarding backup control functions, the func.sgml describes as above. > > But non-exclusive pg_start_backup and pg_stop_backup can also be > > executed during recovery, and

Re: Correction: Postgres emum documentation 8.7.4 should read 63 characters (instead of bytes)

2023-04-02 Thread Erik Wienhold
> On 01/04/2023 00:17 CEST PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/15/datatype-enum.html > Description: > > Postgres documentation, section 8.7.4 gives the limit on enum labels as 63 > bytes. > Te

Small correction in chown command to set the owner of the pgsql data dir correctly

2021-02-07 Thread PG Doc comments form
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/creating-cluster.html Description: "root# mkdir /usr/local/pgsql root# chown postgres /usr/local/pgsql root# su postgres postgres$ initdb -D /usr/local/pgsql/data" If these steps are follo

Re: Small correction in chown command to set the owner of the pgsql data dir correctly

2021-02-07 Thread David G. Johnston
On Saturday, February 6, 2021, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/13/creating-cluster.html > Description: > > "root# mkdir /usr/local/pgsql > root# chown postgres /usr/local/pgsql > root# su p

Re: Small correction in chown command to set the owner of the pgsql data dir correctly

2021-02-07 Thread Tom Lane
"David G. Johnston" writes: > On Saturday, February 6, 2021, PG Doc comments form > wrote: >> "root# mkdir /usr/local/pgsql >> root# chown postgres /usr/local/pgsql >> root# su postgres >> postgres$ initdb -D /usr/local/pgsql/data" >> If these steps are followed then it still fails to initialize