Re: typos

[David Rowley]

( Added Joe and Robert for 0011 )

On Mon, 11 Apr 2022 at 14:03, Justin Pryzby  wrote:
> In docs and comments.  Mostly for v15.

0001:

Should this not use PostgreSQL? (new to master)

0002:

The patch looks good. (new to v12)

0003:

The patch looks good. (new to master)

0004:

The patch looks good. (new to master)

0005:

I'm not entirely certain this is an improvement.  Your commit message
I'd say is not true going by git grep "compression algorithm". There
are 3 matches in the docs and take [1], for example. I'd say in that
one it's better to use "algorithm".  In that case, "method" could be
talking about client or server.

That makes me wonder if the change you're proposing is an improvement or not.

0006:

The patch looks good. (new to master)

0007:

-When the --max-tries option is used, the
transaction with
-serialization or deadlock error cannot be retried if the total time of
+When the --max-tries option is used, a
transaction with
+serialization or deadlock error will not be retried if the
total time of

Shouldn't this be slightly clearer and say "a transaction which fails
due to a serialization anomaly or a deadlock"?

-   database server / the syntax error in the meta command / thread
+   database server / syntax error in the meta command / thread

Should we not separate these items out with commas?

-   the client is aborted. Otherwise, if an SQL fails with serialization or
+   the client is aborted. Otherwise, if an SQL command fails with
serialization or
deadlock errors, the client is not aborted. In such cases, the current

I'd say "if an SQL command fails due to a serialization anomaly or due
to deadlocking".

(new to master)

0008:

The patch looks good. (new to master)

0009:

The patch looks good. (new to master)

0010:

I don't understand this change.

0011:

I can't quite parse the original. I might not have enough context
here.  Robert, Joe? (new to master)

0012:

This seems to contain some documentation fixes too. The patch claims
it's just for comments.

- * pages that are outwith that range.
+ * pages that are outside that range.

I personally don't see the issue here, but I'm Scottish. I think the
best transaction is just "outside of" rather than replacing with just
"outside".

All the other changes look fine.

0013:

I think we should fix all these, regardless of how old the mistake is.

0014:

- * shouldn't PANIC just because we can't guarantee the the backup has been
+ * shouldn't PANIC just because we can't guarantee the backup has been

"that the"

0015:

Patch looks fine.

0016:
0017:

I'm not really sure if we should fix these or not.  From having a
quick look at some of them it seems we'd be adding churn to some
pretty old code. Happy to hear what others think.

0018:

The patch looks good.

0019:

-1. pgindent will fix these.

I will start pushing the less controversial of these, after a bit of squashing.

David

[1] https://www.postgresql.org/docs/devel/app-pgbasebackup.html

Re: typos

[David Rowley]

On Mon, 11 Apr 2022 at 16:39, David Rowley  wrote:
> I will start pushing the less controversial of these, after a bit of 
> squashing.

I just committed 3 separate commits for the following:

Committed: 0001 + 0003 + 0004 + 0006 + 0007 (modified) + 0008 + 0009 +
0012 (doc parts)
Committed: 0012 (remainder) + 0013 + 0014 + 0018
Committed: 0015

I skipped:
0002 (skipped as we should backpatch)
0005 (unsure if the proposed patch is better)
0010 (I can't follow this change)
0011 (Could do with input from Robert and Joe)

and also skipped:
0016 (unsure if we should change these of pgindent is not touching it)
0017 (unsure if we should change these of pgindent is not touching it)
0019 (pgindent will get these when the time comes)

I'll wait for feedback on the ones I didn't use.

Are you able to rebase the remainder? Probably with the exception of 0019.

Thanks for finding all these!

David

Re: typos

[Justin Pryzby]

On Mon, Apr 11, 2022 at 04:39:30PM +1200, David Rowley wrote:
> I'm not entirely certain this is an improvement.  Your commit message
> I'd say is not true going by git grep "compression algorithm". There
> are 3 matches in the docs and take [1], for example. I'd say in that
> one it's better to use "algorithm".  In that case, "method" could be
> talking about client or server.

I am not wedded to this change; but, for context, I wrote this patch before
basebackup supported multiple compression ...  "things".  I didn't touch
basebackup here, since Robert defended that choice of words in another thread
(starting at 20220320194050.gx28...@telsasoft.com).

This change is for pg_column_compression(), and the only other use of
"compression algorithm" in the docs is in pgcrypto (which is in contrib).  That
the docs consistently use "method" suggests continuing to use that rather than
something else.  It could be described in some central place (like if we
support common syntax between interfaces which expose compression).

> 0010:
> I don't understand this change.

The commit message mentions 959f6d6a1, which makes newbindir optional.  But the
documentation wasn't updated, and seems to indicate that it's still required.
https://www.postgresql.org/docs/devel/pgupgrade.html

> 0011:
> I can't quite parse the original. I might not have enough context
> here.  Robert, Joe? (new to master)

See the link in the commit message where someone else reported the same
problem.

> 0019:
> -1. pgindent will fix these.

But two of those are from 2016.

Thanks for amending and pushing those.  There's some more less obvious ones
attached.

Amit or Masahiko may want to comment on 0012 (doc review: Add ALTER
SUBSCRIPTION ... SKIP).
>From 98778834b8c762a6cd76d8680191a7c866397d8b Mon Sep 17 00:00:00 2001
From: Justin Pryzby 
Date: Wed, 16 Feb 2022 21:07:53 -0600
Subject: [PATCH 01/13] doc: Remove 'synchronized' from --no-sync

Since it would be more accurate to say "unsynchronized".

The corresponding change was made for pgupgrade.sgml in commit 410aa248
---
 doc/src/sgml/ref/pg_rewind.sgml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/src/sgml/ref/pg_rewind.sgml b/doc/src/sgml/ref/pg_rewind.sgml
index e808239aa5b..3231f67845a 100644
--- a/doc/src/sgml/ref/pg_rewind.sgml
+++ b/doc/src/sgml/ref/pg_rewind.sgml
@@ -210,7 +210,7 @@ PostgreSQL documentation
 to be written safely to disk.  This option causes
 pg_rewind to return without waiting, which is
 faster, but means that a subsequent operating system crash can leave
-the synchronized data directory corrupt.  Generally, this option is
+the data directory corrupt.  Generally, this option is
 useful for testing but should not be used on a production
 installation.

-- 
2.17.1

>From d4bde4e9acf6375d8894af0a6d5a1557a29174b3 Mon Sep 17 00:00:00 2001
From: Justin Pryzby 
Date: Sat, 19 Feb 2022 11:47:35 -0600
Subject: [PATCH 02/13] doc: pg_column_compression(): we say method not
 algorithm everywhere else

could backpatch to v14
---
 doc/src/sgml/func.sgml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 2ecf0482d84..a34eb8b43e0 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -29285,7 +29285,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset((pg_backup_stop()).lsn);
 text


-Shows the compression algorithm that was used to compress
+Shows the compression method that was used to compress
 an individual variable-length value. Returns NULL
 if the value is not compressed.

-- 
2.17.1

>From fb28ed4be7f82337a8e4aa92140bdafc78ee2278 Mon Sep 17 00:00:00 2001
From: Justin Pryzby 
Date: Mon, 20 Dec 2021 19:13:29 -0600
Subject: [PATCH 03/13] doc review: update synopsis: pg_upgrade optional
 newbindir

See also: 959f6d6a1821b7d9068244f500dd80953e768d16
---
 doc/src/sgml/ref/pgupgrade.sgml | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml
index f024c3ef259..8cda8d16d17 100644
--- a/doc/src/sgml/ref/pgupgrade.sgml
+++ b/doc/src/sgml/ref/pgupgrade.sgml
@@ -24,8 +24,7 @@ PostgreSQL documentation
pg_upgrade
-b
oldbindir
-   -B
-   newbindir
+   -B newbindir
-d
oldconfigdir
-D
-- 
2.17.1

>From cc2480bbdf667369d920459bea0d497e7b7255dc Mon Sep 17 00:00:00 2001
From: Justin Pryzby 
Date: Thu, 7 Apr 2022 09:04:23 -0500
Subject: [PATCH 04/13] doc review: basebackup_to_shell.required_role

c6306db24bd913375f99494e38ab315befe44e11

See also:
https://www.postgresql.org/message-id/CA%2BTgmoaBQ5idAh7OsQGAbLY166SVkj7KkKROkTyN5sOF6QDuww%40mail.gmail.com
---
 doc/src/sgml/basebackup-to-shell.sgml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/src/sgml/basebackup-to-shell.sgml b/doc/src/sgml/basebackup-to-shell.sgml
index 9f44071d502..1

Re: typos

[Masahiko Sawada]

On Mon, Apr 11, 2022 at 7:10 PM Justin Pryzby  wrote:
>
> On Mon, Apr 11, 2022 at 04:39:30PM +1200, David Rowley wrote:
> > I'm not entirely certain this is an improvement.  Your commit message
> > I'd say is not true going by git grep "compression algorithm". There
> > are 3 matches in the docs and take [1], for example. I'd say in that
> > one it's better to use "algorithm".  In that case, "method" could be
> > talking about client or server.
>
> I am not wedded to this change; but, for context, I wrote this patch before
> basebackup supported multiple compression ...  "things".  I didn't touch
> basebackup here, since Robert defended that choice of words in another thread
> (starting at 20220320194050.gx28...@telsasoft.com).
>
> This change is for pg_column_compression(), and the only other use of
> "compression algorithm" in the docs is in pgcrypto (which is in contrib).  
> That
> the docs consistently use "method" suggests continuing to use that rather than
> something else.  It could be described in some central place (like if we
> support common syntax between interfaces which expose compression).
>
> > 0010:
> > I don't understand this change.
>
> The commit message mentions 959f6d6a1, which makes newbindir optional.  But 
> the
> documentation wasn't updated, and seems to indicate that it's still required.
> https://www.postgresql.org/docs/devel/pgupgrade.html
>
> > 0011:
> > I can't quite parse the original. I might not have enough context
> > here.  Robert, Joe? (new to master)
>
> See the link in the commit message where someone else reported the same
> problem.
>
> > 0019:
> > -1. pgindent will fix these.
>
> But two of those are from 2016.
>
> Thanks for amending and pushing those.  There's some more less obvious ones
> attached.
>
> Amit or Masahiko may want to comment on 0012 (doc review: Add ALTER
> SUBSCRIPTION ... SKIP).

Thank you for the patch! I've looked at 0012 patch. Regarding the
following part:

pg_replication_origin_advance() function
-   transaction.  Before using this function, the subscription needs
to be disabled
+   XXX? transaction.  Before using this function, the subscription
needs to be disabled
temporarily either by ALTER SUBSCRIPTION ...
DISABLE or, the

we can remove "transaction", it seems a typo. The rest looks good to me.

Regards,

-- 
Masahiko Sawada
EDB:  https://www.enterprisedb.com/

Re: typos

[Amit Kapila]

On Mon, Apr 11, 2022 at 3:55 PM Masahiko Sawada  wrote:
>
> On Mon, Apr 11, 2022 at 7:10 PM Justin Pryzby  wrote:
> >
> > Amit or Masahiko may want to comment on 0012 (doc review: Add ALTER
> > SUBSCRIPTION ... SKIP).
>
> Thank you for the patch! I've looked at 0012 patch. Regarding the
> following part:
>
> pg_replication_origin_advance() function
> -   transaction.  Before using this function, the subscription needs
> to be disabled
> +   XXX? transaction.  Before using this function, the subscription
> needs to be disabled
> temporarily either by ALTER SUBSCRIPTION ...
> DISABLE or, the
>
> we can remove "transaction", it seems a typo.
>

Right.

> The rest looks good to me.
>

+1. I'll take care of pushing this one tomorrow unless we have more
comments on this part.

-- 
With Regards,
Amit Kapila.

Re: typos

[Robert Haas]

On Mon, Apr 11, 2022 at 4:56 AM David Rowley  wrote:
> 0011 (Could do with input from Robert and Joe)

Seems like a reasonable change to me.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Re: typos

[Amit Kapila]

On Mon, Apr 11, 2022 at 4:15 PM Amit Kapila  wrote:
>
> On Mon, Apr 11, 2022 at 3:55 PM Masahiko Sawada  wrote:
> >
> > On Mon, Apr 11, 2022 at 7:10 PM Justin Pryzby  wrote:
> > >
> > > Amit or Masahiko may want to comment on 0012 (doc review: Add ALTER
> > > SUBSCRIPTION ... SKIP).
> >
>
> +1. I'll take care of pushing this one tomorrow unless we have more
> comments on this part.
>

I have pushed this one.

-- 
With Regards,
Amit Kapila.

Re: typos

[Alvaro Herrera]

On 2022-Apr-11, David Rowley wrote:

> and also skipped:
> 0016 (unsure if we should change these of pgindent is not touching it)
> 0017 (unsure if we should change these of pgindent is not touching it)

I verified that pgindent will indeed not touch these changes by running
before and after.  (I accepted one comment placement from that run that
touched a neighboring line.)

I think pgindent is right not to modify vertical space very much, since
in many cases it amounts to a subjective decision.  The patch seemed a
(small) improvement, and it seems hard to make too much of a fuss about
such things.  Pushed them as a single commit.

I hadn't noticed that Justin had posted a refreshed patch series, so I
don't know if the new ones match what I pushed.

-- 
Álvaro Herrera   48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"Postgres is bloatware by design: it was built to house
 PhD theses." (Joey Hellerstein, SIGMOD annual conference 2002)

Re: typos

[Justin Pryzby]

On Wed, Apr 13, 2022 at 07:29:34PM +0200, Alvaro Herrera wrote:
> On 2022-Apr-11, David Rowley wrote:
> 
> > and also skipped:
> > 0016 (unsure if we should change these of pgindent is not touching it)
> > 0017 (unsure if we should change these of pgindent is not touching it)
> 
> I verified that pgindent will indeed not touch these changes by running
> before and after.  (I accepted one comment placement from that run that
> touched a neighboring line.)
> 
> I think pgindent is right not to modify vertical space very much, since
> in many cases it amounts to a subjective decision.  The patch seemed a
> (small) improvement, and it seems hard to make too much of a fuss about
> such things.  Pushed them as a single commit.
> 
> I hadn't noticed that Justin had posted a refreshed patch series, so I
> don't know if the new ones match what I pushed.

There were no changes - I had resent the patches that removed blank lines so it
was apparent that they were "outstanding" / under discussion.

There's (only) a few remaining.
>From 543b9d77763da814cf1a99938252eb16a0a7d131 Mon Sep 17 00:00:00 2001
From: Justin Pryzby 
Date: Sat, 12 Mar 2022 14:55:18 -0600
Subject: [PATCH 1/4] comment spaces

---
 src/backend/storage/file/fd.c | 2 +-
 src/include/replication/message.h | 2 +-
 src/include/tsearch/ts_type.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/backend/storage/file/fd.c b/src/backend/storage/file/fd.c
index 14b77f28617..24704b6a023 100644
--- a/src/backend/storage/file/fd.c
+++ b/src/backend/storage/file/fd.c
@@ -912,7 +912,7 @@ InitFileAccess(void)
 void
 InitTemporaryFileAccess(void)
 {
-	Assert(SizeVfdCache != 0);	/* InitFileAccess() needs to have run*/
+	Assert(SizeVfdCache != 0);	/* InitFileAccess() needs to have run */
 	Assert(!temporary_files_allowed);	/* call me only once */
 
 	/*
diff --git a/src/include/replication/message.h b/src/include/replication/message.h
index 7d7785292f1..b9686c28550 100644
--- a/src/include/replication/message.h
+++ b/src/include/replication/message.h
@@ -32,7 +32,7 @@ typedef struct xl_logical_message
 extern XLogRecPtr LogLogicalMessage(const char *prefix, const char *message,
 	size_t size, bool transactional);
 
-/* RMGR API*/
+/* RMGR API */
 #define XLOG_LOGICAL_MESSAGE	0x00
 void		logicalmsg_redo(XLogReaderState *record);
 void		logicalmsg_desc(StringInfo buf, XLogReaderState *record);
diff --git a/src/include/tsearch/ts_type.h b/src/include/tsearch/ts_type.h
index a2008f5504b..689b2d1cfb6 100644
--- a/src/include/tsearch/ts_type.h
+++ b/src/include/tsearch/ts_type.h
@@ -171,7 +171,7 @@ typedef struct
 
 extern PGDLLIMPORT const int tsearch_op_priority[OP_COUNT];
 
-/* get operation priority  by its code*/
+/* get operation priority by its code */
 #define OP_PRIORITY(x)	( tsearch_op_priority[(x) - 1] )
 /* get QueryOperator priority */
 #define QO_PRIORITY(x)	OP_PRIORITY(((QueryOperator *) (x))->oper)
-- 
2.17.1

>From e84373bd78d6634781536a96a083cf26c87aa53e Mon Sep 17 00:00:00 2001
From: Justin Pryzby 
Date: Fri, 25 Mar 2022 13:04:48 -0500
Subject: [PATCH 3/4] doc review: locales

f2553d43060edb210b36c63187d52a632448e1d2
---
 doc/src/sgml/charset.sgml| 12 ++--
 doc/src/sgml/ref/initdb.sgml |  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/doc/src/sgml/charset.sgml b/doc/src/sgml/charset.sgml
index d60d3207fd4..b95303fb893 100644
--- a/doc/src/sgml/charset.sgml
+++ b/doc/src/sgml/charset.sgml
@@ -314,7 +314,7 @@ initdb --locale=sv_SE
   A locale can be selected separately for each database.  The SQL command
   CREATE DATABASE and its command-line equivalent
   createdb have options for that.  Use this for example
-  if a database cluster houses databases for multiple tennants with
+  if a database cluster houses databases for multiple tenants with
   different requirements.
  
 
@@ -346,7 +346,7 @@ initdb --locale=sv_SE
 providers.  This specifies which library supplies the locale
 data.  One standard provider name is libc, which uses
 the locales provided by the operating system C library.  These are the
-locales that most tools provided by the operating system use.  Another
+locales used by most tools provided by the operating system.  Another
 provider is icu, which uses the external
 ICUICU library.  ICU locales can
 only be used if support for ICU was configured when PostgreSQL was built.
@@ -361,8 +361,8 @@ initdb --locale=sv_SE
 
 initdb --locale-provider=icu --icu-locale=en
 
-See the description of the respective commands and programs for the
-respective details.  Note that you can mix locale providers on different
+See the description of the respective commands and programs for
+details.  Note that you can mix locale providers at different
 granularities, for example use libc by default for the
 cluster but have one database that uses the icu
 provider, and then have collation objects usi

Re: typos

[David Rowley]

On Mon, 11 Apr 2022 at 22:10, Justin Pryzby  wrote:
> Thanks for amending and pushing those.  There's some more less obvious ones
> attached.

Here are my notes from yesterday that I made when reviewing and
pushing many of the 2nd batch of patches.

0001: Pushed and back patched to v12

0002: Didn't push. Compression method/algorithm.

0003: Pushed and backpatched to v13

0004: Pushed (reviewed by Robert)

0005: Alvaro Pushed
0006: Alvaro Pushed

0007: Not pushed. No space after comment and closing */  pgindent
fixed one of these but not the other 2.  I've not looked into why
pgindent does 1 and not the other 2.

0008: Pushed

I've left out the following change as it does not seem to be bringing
any sort of consistency to the docs overall. It only brings
consistency to a single source file in the docs.

-  You need zstd, if you want to support
+  You need ZSTD, if you want to support

See: git grep -i ">zstd<"

0009:

This contains a few fixes that look correct. Not sure if the following
has any use as a change:

-See the description of the respective commands and programs for the
-respective details.  Note that you can mix locale providers on different
+See the description of the respective commands and programs for
+details.  Note that you can mix locale providers at different

0010: Pushed

0011: Not pushed. Not sure if this is worth the change.

0012: Amit Pushed

0013: Not pushed. Adds a missing comma.

David

Re: typos

[David Rowley]

(For the future, just to make discussions easier, it would be good if
you could have git format-patch -v N to give a unique version number
to these patches)

On Thu, 14 Apr 2022 at 05:40, Justin Pryzby  wrote:
> There's (only) a few remaining.

I've pushed 0001 and 0002 of the 3rd batch of patches. I left 0003 as
I just didn't feel it was a meaningful enough improvement.

>From docs/, if I do:

$ git grep ", which is the default" | wc -l
9

$ git grep ", the default" | wc -l
64

You're proposing to make the score 10, 63.  I'm not sure if that's a
good direction to go in.

David

Re: typos

[Justin Pryzby]

On Thu, Apr 14, 2022 at 09:39:42AM +1200, David Rowley wrote:
> On Thu, 14 Apr 2022 at 05:40, Justin Pryzby  wrote:
> > There's (only) a few remaining.
> 
> I've pushed 0001 and 0002 of the 3rd batch of patches. I left 0003 as

Thanks

> I just didn't feel it was a meaningful enough improvement.
> 
> From docs/, if I do:
> 
> $ git grep ", which is the default" | wc -l
> 9
> 
> $ git grep ", the default" | wc -l
> 64
> 
> You're proposing to make the score 10, 63.  I'm not sure if that's a
> good direction to go in.

Well, I'm proposing to change the only instance of this:

$ git grep -F ", the default)"
doc/src/sgml/ref/create_publication.sgml:   partition's row filter (if the 
parameter is false, the default) or the root

Maybe what's needed is more like this.

   If the publication contains a partitioned table, and the publication 
parameter
   publish_via_partition_root is false (the default), then 
the
   row filter is taken from the partition; otherwise, the row filter is taken
   from the root partitioned table.

I'll plan to keep this around and may come back to it later.

On Thu, Apr 14, 2022 at 08:56:22AM +1200, David Rowley wrote:
> I've left out the following change as it does not seem to be bringing
> any sort of consistency to the docs overall. It only brings
> consistency to a single source file in the docs.
> 
> -  You need zstd, if you want to support
> +  You need ZSTD, if you want to support
> 
> See: git grep -i ">zstd<"

It may not be worth changing just this one line, but the reason I included it
here is for consistency:

$ git grep 'zstd.*product' doc
doc/src/sgml/config.sgml:zstd (if 
PostgreSQL
$ git grep 'ZSTD.*product' doc
doc/src/sgml/install-windows.sgml: 
ZSTD
doc/src/sgml/install-windows.sgml:  Required for supporting 
ZSTD compression
doc/src/sgml/installation.sgml:  You need ZSTD, 
if you want to support
doc/src/sgml/installation.sgml: Build with 
ZSTD compression support.

If we were to change it, maybe they should all say "Zstandard (zstd)".  ZSTD
looks like an acronym, which I think it is not, and Zstandard indicates how to
pronounce it.

Re: typos

[Alvaro Herrera]

CCing Amit K, because I propose a few relatively minor changes to
logical rep docs.

On 2022-Apr-13, Justin Pryzby wrote:

> $ git grep -F ", the default)"
> doc/src/sgml/ref/create_publication.sgml:   partition's row filter (if the 
> parameter is false, the default) or the root
> 
> Maybe what's needed is more like this.
> 
>If the publication contains a partitioned table, and the publication 
> parameter
>publish_via_partition_root is false (the default), then 
> the
>row filter is taken from the partition; otherwise, the row filter is taken
>from the root partitioned table.

Yeah, more invasive rewording seems called for.  I propose this:

   For publications containing partitioned tables, the row filter for each
   partition is taken from the published partitioned table if the
   publication parameter publish_via_partition_root is true,
   or from the partition itself if it is false (the default).

I think we should also mention that this parameter affects row filters,
in the  for the WITH clause.  Currently it has

publish_via_partition_root 
(boolean)

 
  This parameter determines whether changes in a partitioned table (or
  on its partitions) contained in the publication will be published
  using the identity and schema of the partitioned table rather than
  that of the individual partitions that are actually changed; the
  latter is the default.  Enabling this allows the changes to be
  replicated into a non-partitioned table or a partitioned table
  consisting of a different set of partitions.
 

I propose to add 

publish_via_partition_root 
(boolean)

 
  This parameter determines whether changes in a partitioned table (or
  on its partitions) contained in the publication will be published
  using the identity and schema of the partitioned table rather than
  that of the individual partitions that are actually changed; the
  latter is the default.  Enabling this allows the changes to be
  replicated into a non-partitioned table or a partitioned table
  consisting of a different set of partitions.
 


 This parameter also affects how row filters are chosen for partitions;
 see below for details.


More generally, I think we need to connect the WHERE keyword with "row
filters" more explicitly.  Right now, the parameter reference says

  If the optional WHERE clause is specified, rows for
  which the expression
  evaluates to false or null will not be published. Note that parentheses
  are required around the expression. It has no effect on
  TRUNCATE commands.

I propose to make it "If the optional WHERE clause is specified, it
defines a row filter expression.  Rows for which
the row filter expression evaluates to false ..."


> $ git grep 'zstd.*product' doc
> doc/src/sgml/config.sgml:zstd (if 
> PostgreSQL
> $ git grep 'ZSTD.*product' doc
> doc/src/sgml/install-windows.sgml: 
> ZSTD
> doc/src/sgml/install-windows.sgml:  Required for supporting 
> ZSTD compression
> doc/src/sgml/installation.sgml:  You need 
> ZSTD, if you want to support
> doc/src/sgml/installation.sgml: Build with 
> ZSTD compression support.

I don't see any official sources calling it all-uppercase ZSTD.  In a
quick non-scientific survey, most seem to use Zstd or zstd.  The
non-abbreviated official name is Zstandard, but it's hard to find any
places using that spelling, and I don't think our docs are a place to
educate people on what the official name or pronunciation is.

I propose we standardize on Zstd everywhere.
Users can look it up if they're really interested.

-- 
Álvaro Herrera PostgreSQL Developer  —  https://www.EnterpriseDB.com/

Re: typos

[Michael Paquier]

On Fri, Dec 30, 2022 at 05:12:57PM -0600, Justin Pryzby wrote:

 # Use larger ccache cache, as this task compiles with multiple compilers /
 # flag combinations
-CCACHE_MAXSIZE: "1GB"
+CCACHE_MAXSIZE: "1G"

In 0006, I am not sure how much this matters.  Perhaps somebody more
fluent with Cirrus, though, has a different opinion..

  * pointer to this structure.  The information here must be sufficient to
  * properly initialize each new TableScanDesc as workers join the scan, and it
- * must act as a information what to scan for those workers.
+ * must provide information what to scan for those workers.

This comment in 0009 is obviously incorrect, but I am not sure whether
your new suggestion is an improvement.  Do workers provide such
information or has this structure some information that the workers
rely on?

Not sure that the whitespace issue in 0021 for the header of inval.c
is worth caring about.

0014 and 0013 do not reduce the translation workload, as the messages
include some stuff specific to the GUC names accessed to, or some
specific details about the code paths triggered.

The rest has been applied where they matter.
--
Michael


signature.asc
Description: PGP signature

Re: typos

[Amit Kapila]

On Tue, Jan 3, 2023 at 12:58 PM Michael Paquier  wrote:
>
> On Fri, Dec 30, 2022 at 05:12:57PM -0600, Justin Pryzby wrote:
>
>  # Use larger ccache cache, as this task compiles with multiple compilers 
> /
>  # flag combinations
> -CCACHE_MAXSIZE: "1GB"
> +CCACHE_MAXSIZE: "1G"
>
> In 0006, I am not sure how much this matters.
>

The other places in that file use M, so maybe, this is more consistent.

One minor comment:
-spoken in Belgium (BE), with a UTF-8 character set
+spoken in Belgium (BE), with a UTF-8 character set

Shouldn't this be UTF8 as we are using in func.sgml?

-- 
With Regards,
Amit Kapila.

Re: typos

[Michael Paquier]

On Tue, Jan 03, 2023 at 01:03:01PM +0530, Amit Kapila wrote:
> One minor comment:
> -spoken in Belgium (BE), with a UTF-8 character set
> +spoken in Belgium (BE), with a UTF-8 character set
> 
> Shouldn't this be UTF8 as we are using in func.sgml?

Yeah, I was wondering as well why this change is not worse, which is
why I left it out of 33ab0a2.  There is an acronym for UTF in
acronym.sgml, which makes sense to me, but that's the only place where 
this is used.  To add more on top of that, the docs basically need
only UTF8, and we have three references to UTF-16, none of them using
the  markup.
--
Michael


signature.asc
Description: PGP signature

Re: typos

[Peter Eisentraut]

On 03.01.23 09:41, Michael Paquier wrote:

On Tue, Jan 03, 2023 at 01:03:01PM +0530, Amit Kapila wrote:

One minor comment:
-spoken in Belgium (BE), with a UTF-8 character set
+spoken in Belgium (BE), with a UTF-8 character set

Shouldn't this be UTF8 as we are using in func.sgml?


Yeah, I was wondering as well why this change is not worse, which is
why I left it out of 33ab0a2.  There is an acronym for UTF in
acronym.sgml, which makes sense to me, but that's the only place where
this is used.  To add more on top of that, the docs basically need
only UTF8, and we have three references to UTF-16, none of them using
the  markup.


The thing is called "UTF-8".  Here, we are not talking about the 
PostgreSQL identifier.

Re: typos

[Justin Pryzby]

On Tue, Jan 03, 2023 at 04:28:29PM +0900, Michael Paquier wrote:
> On Fri, Dec 30, 2022 at 05:12:57PM -0600, Justin Pryzby wrote:
> 
>  # Use larger ccache cache, as this task compiles with multiple compilers 
> /
>  # flag combinations
> -CCACHE_MAXSIZE: "1GB"
> +CCACHE_MAXSIZE: "1G"
> 
> In 0006, I am not sure how much this matters.  Perhaps somebody more
> fluent with Cirrus, though, has a different opinion..

It's got almost nothing to do with cirrus.  It's an environment
variable, and we're using a suffix other than what's
supported/documented by ccache, which only happens to work.

> 0014 and 0013 do not reduce the translation workload, as the messages
> include some stuff specific to the GUC names accessed to, or some
> specific details about the code paths triggered.

It seems to matter because otherwise the translators sometimes re-type
the view name, which (not surprisingly) can get messed up, which is how
I mentioned having noticed this.

On Tue, Jan 03, 2023 at 05:41:58PM +0900, Michael Paquier wrote:
> On Tue, Jan 03, 2023 at 01:03:01PM +0530, Amit Kapila wrote:
> > One minor comment:
> > -spoken in Belgium (BE), with a UTF-8
> > character set
> > +spoken in Belgium (BE), with a UTF-8
> > character set
> > 
> > Shouldn't this be UTF8 as we are using in
> > func.sgml?
> 
> Yeah, I was wondering as well why this change is not worse, which is
> why I left it out of 33ab0a2.  There is an acronym for UTF in
> acronym.sgml, which makes sense to me, but that's the only place where 
> this is used.  To add more on top of that, the docs basically need
> only UTF8, and we have three references to UTF-16, none of them using
> the  markup.

I changed it for consistency, as it's the only thing that says <>UTF-8<>
anywhere, and charset.sgml already says <>UTF<>-8 elsewhere.

Alternately, I suggest to change charset to say <>UTF8<> in both places.

-- 
Justin

Re: typos

[Justin Pryzby]

On Tue, Jan 03, 2023 at 03:39:22PM -0600, Justin Pryzby wrote:
> On Tue, Jan 03, 2023 at 04:28:29PM +0900, Michael Paquier wrote:
> > On Fri, Dec 30, 2022 at 05:12:57PM -0600, Justin Pryzby wrote:
> > 
> >  # Use larger ccache cache, as this task compiles with multiple 
> > compilers /
> >  # flag combinations
> > -CCACHE_MAXSIZE: "1GB"
> > +CCACHE_MAXSIZE: "1G"
> > 
> > In 0006, I am not sure how much this matters.  Perhaps somebody more
> > fluent with Cirrus, though, has a different opinion..
> 
> It's got almost nothing to do with cirrus.  It's an environment
> variable, and we're using a suffix other than what's
> supported/documented by ccache, which only happens to work.
> 
> > 0014 and 0013 do not reduce the translation workload, as the messages
> > include some stuff specific to the GUC names accessed to, or some
> > specific details about the code paths triggered.
> 
> It seems to matter because otherwise the translators sometimes re-type
> the view name, which (not surprisingly) can get messed up, which is how
> I mentioned having noticed this.
> 
> On Tue, Jan 03, 2023 at 05:41:58PM +0900, Michael Paquier wrote:
> > On Tue, Jan 03, 2023 at 01:03:01PM +0530, Amit Kapila wrote:
> > > One minor comment:
> > > -spoken in Belgium (BE), with a UTF-8
> > > character set
> > > +spoken in Belgium (BE), with a UTF-8
> > > character set
> > > 
> > > Shouldn't this be UTF8 as we are using in
> > > func.sgml?
> > 
> > Yeah, I was wondering as well why this change is not worse, which is
> > why I left it out of 33ab0a2.  There is an acronym for UTF in
> > acronym.sgml, which makes sense to me, but that's the only place where 
> > this is used.  To add more on top of that, the docs basically need
> > only UTF8, and we have three references to UTF-16, none of them using
> > the  markup.
> 
> I changed it for consistency, as it's the only thing that says <>UTF-8<>
> anywhere, and charset.sgml already says <>UTF<>-8 elsewhere.
> 
> Alternately, I suggest to change charset to say <>UTF8<> in both places.

As attached.
This also fixes "specualtive" in Amit's recent commit.

-- 
Justin
>From 8b56d6007e13e3b42bc75da3b9174ecab8a8dd70 Mon Sep 17 00:00:00 2001
From: Justin Pryzby 
Date: Sun, 25 Sep 2022 18:40:36 -0500
Subject: [PATCH 1/9] typos

---
 .cirrus.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.cirrus.yml b/.cirrus.yml
index 69837bcd5ad..048a004e309 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -655,7 +655,7 @@ task:
 
 # Use larger ccache cache, as this task compiles with multiple compilers /
 # flag combinations
-CCACHE_MAXSIZE: "1GB"
+CCACHE_MAXSIZE: "1G"
 CCACHE_DIR: "/tmp/ccache_dir"
 
 LINUX_CONFIGURE_FEATURES: *LINUX_CONFIGURE_FEATURES
-- 
2.25.1

>From c082768a857ebd7a0a534ee497761dca0c621f64 Mon Sep 17 00:00:00 2001
From: Justin Pryzby 
Date: Sun, 26 Sep 2021 11:13:27 -0500
Subject: [PATCH 2/9] comments grammar: extended (and other) stats

See:
202109272104.7t253iw236fb@alvherre.pgsql
070d2e19e40897d857f570f24888fc30727ed9c0
609b0652af00374b89411ea2613fd5bb92bca92c
a4d75c86bf15220df22de0a92c819ecef9db3849
7300a699502fe5432b05fbc75baca534b080bebb
ccaa3569f58796868303629bc2d63b599b38
---
 src/backend/commands/statscmds.c | 4 ++--
 src/backend/statistics/README| 2 +-
 src/backend/statistics/dependencies.c| 8 
 src/backend/statistics/extended_stats.c  | 4 ++--
 src/backend/utils/adt/pgstatfuncs.c  | 4 ++--
 src/backend/utils/adt/ruleutils.c| 2 +-
 src/include/statistics/extended_stats_internal.h | 2 +-
 7 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/src/backend/commands/statscmds.c b/src/backend/commands/statscmds.c
index 26ebd0819d6..2e41745646b 100644
--- a/src/backend/commands/statscmds.c
+++ b/src/backend/commands/statscmds.c
@@ -377,7 +377,7 @@ CreateStatistics(CreateStatsStmt *stmt)
 
 	/*
 	 * If no statistic type was specified, build them all (but only when the
-	 * statistics is defined on more than one column/expression).
+	 * statistics object is defined on more than one column/expression).
 	 */
 	if ((!requested_type) && (numcols >= 2))
 	{
@@ -432,7 +432,7 @@ CreateStatistics(CreateStatsStmt *stmt)
 	 * similar to why we don't bother with extracting columns from
 	 * expressions. It's either expensive or very easy to defeat for
 	 * determined user, and there's no risk if we allow such statistics (the
-	 * statistics is useless, but harmless).
+	 * statistic is useless, but harmless).
 	 */
 	foreach(cell, stxexprs)
 	{
diff --git a/src/backend/statistics/README b/src/backend/statistics/README
index 13a97a35662..b87ca4734b2 100644
--- a/src/backend/statistics/README
+++ b/src/backend/statistics/README
@@ -24,7 +24,7 @@ There are currently several kinds of extended statistics:
 Compatible clause types
 ---
 
-Each type of statistics may be used to estimate some subset of clause types.
+E

Re: typos

[Amit Kapila]

On Tue, Jan 10, 2023 at 10:27 AM Justin Pryzby  wrote:
>
> On Tue, Jan 03, 2023 at 03:39:22PM -0600, Justin Pryzby wrote:
> > On Tue, Jan 03, 2023 at 04:28:29PM +0900, Michael Paquier wrote:
> > > On Fri, Dec 30, 2022 at 05:12:57PM -0600, Justin Pryzby wrote:
> > >
> > >  # Use larger ccache cache, as this task compiles with multiple 
> > > compilers /
> > >  # flag combinations
> > > -CCACHE_MAXSIZE: "1GB"
> > > +CCACHE_MAXSIZE: "1G"
> > >
> > > In 0006, I am not sure how much this matters.  Perhaps somebody more
> > > fluent with Cirrus, though, has a different opinion..
> >
> > It's got almost nothing to do with cirrus.  It's an environment
> > variable, and we're using a suffix other than what's
> > supported/documented by ccache, which only happens to work.
> >
> > > 0014 and 0013 do not reduce the translation workload, as the messages
> > > include some stuff specific to the GUC names accessed to, or some
> > > specific details about the code paths triggered.
> >
> > It seems to matter because otherwise the translators sometimes re-type
> > the view name, which (not surprisingly) can get messed up, which is how
> > I mentioned having noticed this.
> >
> > On Tue, Jan 03, 2023 at 05:41:58PM +0900, Michael Paquier wrote:
> > > On Tue, Jan 03, 2023 at 01:03:01PM +0530, Amit Kapila wrote:
> > > > One minor comment:
> > > > -spoken in Belgium (BE), with a UTF-8
> > > > character set
> > > > +spoken in Belgium (BE), with a UTF-8
> > > > character set
> > > >
> > > > Shouldn't this be UTF8 as we are using in
> > > > func.sgml?
> > >
> > > Yeah, I was wondering as well why this change is not worse, which is
> > > why I left it out of 33ab0a2.  There is an acronym for UTF in
> > > acronym.sgml, which makes sense to me, but that's the only place where
> > > this is used.  To add more on top of that, the docs basically need
> > > only UTF8, and we have three references to UTF-16, none of them using
> > > the  markup.
> >
> > I changed it for consistency, as it's the only thing that says <>UTF-8<>
> > anywhere, and charset.sgml already says <>UTF<>-8 elsewhere.
> >
> > Alternately, I suggest to change charset to say <>UTF8<> in both places.
>
> As attached.
> This also fixes "specualtive" in Amit's recent commit.
>

Thanks for noticing this. I'll take care of this and some other typo
patches together.

-- 
With Regards,
Amit Kapila.

Re: typos

[Michael Paquier]

On Tue, Jan 10, 2023 at 12:24:40PM +0530, Amit Kapila wrote:
> Thanks for noticing this. I'll take care of this and some other typo
> patches together.

Does this include 0010?  I was just looking at the whole set and this
one looked like a cleanup worth on its own so I was going to handle
it, until I saw your update.  If you are also looking at that, I won't
stand in your way, of course :) 
--
Michael


signature.asc
Description: PGP signature

Re: typos

[Amit Kapila]

On Tue, Jan 10, 2023 at 1:18 PM Michael Paquier  wrote:
>
> On Tue, Jan 10, 2023 at 12:24:40PM +0530, Amit Kapila wrote:
> > Thanks for noticing this. I'll take care of this and some other typo
> > patches together.
>
> Does this include 0010?  I was just looking at the whole set and this
> one looked like a cleanup worth on its own so I was going to handle
> it, until I saw your update.  If you are also looking at that, I won't
> stand in your way, of course :)
>

I have not yet started, so please go ahead.

-- 
With Regards,
Amit Kapila.

Re: typos

[Michael Paquier]

On Tue, Jan 10, 2023 at 01:55:56PM +0530, Amit Kapila wrote:
> I have not yet started, so please go ahead.

Okay, I have looked at that and fixed the whole new things, including
the typo you have introduced.  0001~0004 have been left out, as of the
same reasons as upthread.
--
Michael


signature.asc
Description: PGP signature

Re: typos

[Justin Pryzby]

Some more accumulated/new typos.
>From 6c79a0d4e0251dbbac38babb60bb2d0fbae3da8d Mon Sep 17 00:00:00 2001
From: Justin Pryzby 
Date: Wed, 11 Jan 2023 12:52:25 -0600
Subject: [PATCH 01/10] use "an SQL" rather than a SQL

Per 04539e
---
 doc/src/sgml/ecpg.sgml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/doc/src/sgml/ecpg.sgml b/doc/src/sgml/ecpg.sgml
index a76cf3538f1..f52165165dc 100644
--- a/doc/src/sgml/ecpg.sgml
+++ b/doc/src/sgml/ecpg.sgml
@@ -1506,7 +1506,7 @@ EXEC SQL TYPE serial_t IS long;
  
 
  
-  Any word you declare as a typedef cannot be used as a SQL keyword
+  Any word you declare as a typedef cannot be used as an SQL keyword
   in EXEC SQL commands later in the same program.
   For example, this won't work:
 
@@ -1518,7 +1518,7 @@ EXEC SQL START TRANSACTION;
 
   ECPG will report a syntax error for START
   TRANSACTION, because it no longer
-  recognizes START as a SQL keyword,
+  recognizes START as an SQL keyword,
   only as a typedef.
   (If you have such a conflict, and renaming the typedef
   seems impractical, you could write the SQL command
@@ -1530,7 +1530,7 @@ EXEC SQL START TRANSACTION;
In PostgreSQL releases before v16, use
of SQL keywords as typedef names was likely to result in syntax
errors associated with use of the typedef itself, rather than use
-   of the name as a SQL keyword.  The new behavior is less likely to
+   of the name as an SQL keyword.  The new behavior is less likely to
cause problems when an existing ECPG application is recompiled in
a new PostgreSQL release with new
keywords.
-- 
2.25.1

>From fef49b822bad849722ec9b043ffd676c80492d0d Mon Sep 17 00:00:00 2001
From: Justin Pryzby 
Date: Sun, 15 Jan 2023 17:00:06 -0600
Subject: [PATCH 02/10] comment typos

---
 src/backend/commands/dbcommands.c  | 2 +-
 src/backend/executor/execMain.c| 2 +-
 src/backend/jit/llvm/llvmjit_inline.cpp| 2 +-
 src/backend/replication/logical/snapbuild.c| 2 +-
 src/backend/replication/walsender.c| 6 +++---
 src/bin/pg_dump/pg_backup_custom.c | 2 +-
 src/bin/pg_dump/pg_dumpall.c   | 2 +-
 src/include/lib/ilist.h| 2 +-
 src/test/regress/expected/alter_table.out  | 2 +-
 src/test/regress/expected/create_procedure.out | 2 +-
 src/test/regress/sql/alter_table.sql   | 2 +-
 src/test/regress/sql/create_procedure.sql  | 2 +-
 src/test/subscription/t/031_column_list.pl | 2 +-
 13 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/src/backend/commands/dbcommands.c b/src/backend/commands/dbcommands.c
index 1f4ce2fb9cf..ef05633bb05 100644
--- a/src/backend/commands/dbcommands.c
+++ b/src/backend/commands/dbcommands.c
@@ -3090,7 +3090,7 @@ dbase_redo(XLogReaderState *record)
 
 		/*
 		 * There's a case where the copy source directory is missing for the
-		 * same reason above.  Create the emtpy source directory so that
+		 * same reason above.  Create the empty source directory so that
 		 * copydir below doesn't fail.  The directory will be dropped soon by
 		 * recovery.
 		 */
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index a5115b9c1f7..39bfb48dc22 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -134,7 +134,7 @@ ExecutorStart(QueryDesc *queryDesc, int eflags)
 	/*
 	 * In some cases (e.g. an EXECUTE statement) a query execution will skip
 	 * parse analysis, which means that the query_id won't be reported.  Note
-	 * that it's harmless to report the query_id multiple time, as the call
+	 * that it's harmless to report the query_id multiple times, as the call
 	 * will be ignored if the top level query_id has already been reported.
 	 */
 	pgstat_report_query_id(queryDesc->plannedstmt->queryId, false);
diff --git a/src/backend/jit/llvm/llvmjit_inline.cpp b/src/backend/jit/llvm/llvmjit_inline.cpp
index dc35e002f51..c765add8564 100644
--- a/src/backend/jit/llvm/llvmjit_inline.cpp
+++ b/src/backend/jit/llvm/llvmjit_inline.cpp
@@ -753,7 +753,7 @@ function_inlinable(llvm::Function &F,
 		/* import referenced function itself */
 		importVars.insert(referencedFunction->getName());
 
-		/* import referenced function and its dependants */
+		/* import referenced function and its dependents */
 		for (auto& recImportVar : recImportVars)
 			importVars.insert(recImportVar.first());
 	}
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index 829c5681120..62542827e4b 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -1816,7 +1816,7 @@ SnapBuildSerialize(SnapBuild *builder, XLogRecPtr lsn)
 	fsync_fname("pg_logical/snapshots", true);
 
 	/*
-	 * Now there's no way we can loose the dumped state anymore, remember this
+	 * Now there's no way we can lose the d

Re: typos

[Michael Paquier]

On Wed, Feb 08, 2023 at 09:56:44AM -0600, Justin Pryzby wrote:
> Some more accumulated/new typos.

0001 has been a debate for a long time, and it depends on the way SQL
is spelled.  For reference:
$ git grep -i " an sql" -- *.c | wc -l
63
$ git grep -i " a sql" -- *.c | wc -l
135

0005 can indeed fix a lot of confusion around the spaces after an
"else if" block.  Is that something that could be automated with the
indentation, though?  Same remark for 0009 and 0010.

Applied 0002, 0003, 0004, 0006, after rewording a bit 0003 to mention
the compression type.
--
Michael


signature.asc
Description: PGP signature

Re: typos

[Tom Lane]

Michael Paquier  writes:
> On Wed, Feb 08, 2023 at 09:56:44AM -0600, Justin Pryzby wrote:
>> Some more accumulated/new typos.

> 0005 can indeed fix a lot of confusion around the spaces after an
> "else if" block.  Is that something that could be automated with the
> indentation, though?  Same remark for 0009 and 0010.

I see your point about 0005, but I've never seen pgindent remove
vertical whitespace once it's been added.  Not sure what it'd take
to teach it to do so, or whether we'd like the results.

I'd reject 0009 and 0010 altogether --- they don't add any readability
that's worth the potential increase in back-patch problems.

regards, tom lane

Re: typos

[Michael Paquier]

On Sun, Jan 23, 2022 at 09:00:01PM -0600, Justin Pryzby wrote:
> Feel free to ignore this for now and revisit in April...

I don't mind fixing that now.  That means less to do later.

> @Michael: I'm not sure what this is trying to say.
> 1e9475694b0ae2cf1204d01d2ef6ad86f3c7cac8
> +  First, scan the directory where the WAL segment files are written and
> +  find the newest completed segment file, using as starting point the
> +  beginning of the next WAL segment file. This is calculated 
> independently
> +  on the compression method used to compress each segment.
> 
> I suppose it should say independently *of* the compression method, but then I
> still don't know what it means.  I checked FindStreamingStart().
> It that doesn't look like it's "calculated independently" - actually, it takes
> the compression method into account and explicitly handles each compression
> method.

This means that we are able to calculate the starting LSN even if the
segments stored use different compression methods or are
uncompressed.  Would you reword that differently?  Or perhaps removing
the last sentence of this paragraph would be simpler in the long run?
--
Michael


signature.asc
Description: PGP signature

Re: typos

[Justin Pryzby]

On Mon, Jan 24, 2022 at 04:01:47PM +0900, Michael Paquier wrote:
> On Sun, Jan 23, 2022 at 09:00:01PM -0600, Justin Pryzby wrote:
> > Feel free to ignore this for now and revisit in April...
> 
> I don't mind fixing that now.  That means less to do later.

Thanks.

> > @Michael: I'm not sure what this is trying to say.
> > 1e9475694b0ae2cf1204d01d2ef6ad86f3c7cac8
> > +  First, scan the directory where the WAL segment files are written and
> > +  find the newest completed segment file, using as starting point the
> > +  beginning of the next WAL segment file. This is calculated 
> > independently
> > +  on the compression method used to compress each segment.
> > 
> > I suppose it should say independently *of* the compression method, but then 
> > I
> > still don't know what it means.  I checked FindStreamingStart().
> > It that doesn't look like it's "calculated independently" - actually, it 
> > takes
> > the compression method into account and explicitly handles each compression
> > method.
> 
> This means that we are able to calculate the starting LSN even if the
> segments stored use different compression methods or are
> uncompressed.  Would you reword that differently?  Or perhaps removing
> the last sentence of this paragraph would be simpler in the long run?

different from what?  From each other ?

Maybe I would have written:
| This is calculated separately for each segment, which may each use
| different compression methods.

But probably I would just remove it.

-- 
Justin

Re: typos

[Michael Paquier]

On Mon, Jan 24, 2022 at 01:07:54AM -0600, Justin Pryzby wrote:
> different from what?  From each other ?

Each segment could be either uncompressed, compressed with LZ4, or
compressed with GZIP, so could be different from each other.

> Maybe I would have written:
> | This is calculated separately for each segment, which may each use
> | different compression methods.
> 
> But probably I would just remove it.

I'm thinking about just removing that at the end.
--
Michael


signature.asc
Description: PGP signature

Re: typos

[Michael Paquier]

On Mon, Jan 24, 2022 at 04:55:31PM +0900, Michael Paquier wrote:
> I'm thinking about just removing that at the end.

And done this way, keeping the whole simpler.  I have applied most of
the things you suggested, with a backpatch down to 10 for the relevant
user-visible parts in the docs.  Thanks!
--
Michael


signature.asc
Description: PGP signature

Re: typos

[Noah Misch]

On Thu, Apr 14, 2022 at 08:56:22AM +1200, David Rowley wrote:
> 0007: Not pushed. No space after comment and closing */  pgindent
> fixed one of these but not the other 2.  I've not looked into why
> pgindent does 1 and not the other 2.

> -/* get operation priority  by its code*/
> +/* get operation priority by its code */

pgindent never touches comments that start in column zero.  (That's why many
column-0 comments are wrapped to widths other than the standard 78.)

Re: typos

[Amit Kapila]

On Tue, Apr 19, 2022 at 4:35 PM Alvaro Herrera  wrote:
>
> Yeah, more invasive rewording seems called for.  I propose this:
>
>For publications containing partitioned tables, the row filter for each
>partition is taken from the published partitioned table if the
>publication parameter publish_via_partition_root is 
> true,
>or from the partition itself if it is false (the default).
>
> I think we should also mention that this parameter affects row filters,
> in the  for the WITH clause.  Currently it has
>
> publish_via_partition_root 
> (boolean)
> 
>  
>   This parameter determines whether changes in a partitioned table (or
>   on its partitions) contained in the publication will be published
>   using the identity and schema of the partitioned table rather than
>   that of the individual partitions that are actually changed; the
>   latter is the default.  Enabling this allows the changes to be
>   replicated into a non-partitioned table or a partitioned table
>   consisting of a different set of partitions.
>  
>
> I propose to add
>
> publish_via_partition_root 
> (boolean)
> 
>  
>   This parameter determines whether changes in a partitioned table (or
>   on its partitions) contained in the publication will be published
>   using the identity and schema of the partitioned table rather than
>   that of the individual partitions that are actually changed; the
>   latter is the default.  Enabling this allows the changes to be
>   replicated into a non-partitioned table or a partitioned table
>   consisting of a different set of partitions.
>  
>
> 
>  This parameter also affects how row filters are chosen for 
> partitions;
>  see below for details.
> 
>

Your proposed changes look good to me but I think all these places
need to mention 'column list' as well because the behavior is the same
for it.

> More generally, I think we need to connect the WHERE keyword with "row
> filters" more explicitly.  Right now, the parameter reference says
>
>   If the optional WHERE clause is specified, rows for
>   which the expression
>   evaluates to false or null will not be published. Note that parentheses
>   are required around the expression. It has no effect on
>   TRUNCATE commands.
>
> I propose to make it "If the optional WHERE clause is specified, it
> defines a row filter expression.  Rows for which
> the row filter expression evaluates to false ..."
>

Looks good to me.

-- 
With Regards,
Amit Kapila.

Re: typos

[Alvaro Herrera]

On 2022-Apr-20, Amit Kapila wrote:

> Your proposed changes look good to me but I think all these places
> need to mention 'column list' as well because the behavior is the same
> for it.

Hmm, you're right.  Added that, and changed the wording somewhat because
some things read awkwardly.  Here's the result in patch form.

Column lists seems not mentioned in logical-replication.sgml, either.

-- 
Álvaro HerreraBreisgau, Deutschland  —  https://www.EnterpriseDB.com/
"La verdad no siempre es bonita, pero el hambre de ella sí"
diff --git a/doc/src/sgml/ref/create_publication.sgml b/doc/src/sgml/ref/create_publication.sgml
index 23d883c158..c58478e8f8 100644
--- a/doc/src/sgml/ref/create_publication.sgml
+++ b/doc/src/sgml/ref/create_publication.sgml
@@ -79,7 +79,8 @@ CREATE PUBLICATION name
  
 
  
-  If the optional WHERE clause is specified, rows for
+  If the optional WHERE clause is specified, it defines a
+  row filter expression. Rows for
   which the expression
   evaluates to false or null will not be published. Note that parentheses
   are required around the expression. It has no effect on
@@ -192,6 +193,11 @@ CREATE PUBLICATION name
   consisting of a different set of partitions.
  
 
+ 
+  This parameter also affects how row filters and column lists are
+  chosen for partitions; see below for details.
+ 
+
  
   If this is enabled, TRUNCATE operations performed
   directly on partitions are not replicated.
@@ -241,21 +247,28 @@ CREATE PUBLICATION name
   
 
   
-   A WHERE (i.e. row filter) expression must contain only
+   A row filter expression (i.e., the WHERE clause) must contain only
columns that are covered by the REPLICA IDENTITY, in
order for UPDATE and DELETE operations
to be published. For publication of INSERT operations,
any column may be used in the WHERE expression. The
-   WHERE clause allows simple expressions that don't have
+   row filter allows simple expressions that don't have
user-defined functions, user-defined operators, user-defined types,
user-defined collations, non-immutable built-in functions, or references to
system columns.
-   If your publication contains a partitioned table, the publication parameter
-   publish_via_partition_root determines if it uses the
-   partition's row filter (if the parameter is false, the default) or the root
-   partitioned table's row filter.
+  
+  
+  
+   For published partitioned tables, the row filter for each
+   partition is taken from the published partitioned table if the
+   publication parameter publish_via_partition_root is true,
+   or from the partition itself if it is false (the default).
See  for details about row
filters.
+   Similarly, for published partitioned tables, the column list for each
+   partition is taken from the published partitioned table if the
+   publication parameter publish_via_partition_root is true,
+   or from the partition itself if it is false.
   
 
   

Re: typos

[Alvaro Herrera]

On 2022-Apr-19, Alvaro Herrera wrote:

> I propose we standardize on Zstd everywhere.
> Users can look it up if they're really interested.

So the attached.

There are other uses of zstd, but those are referring to the
executable program.

-- 
Álvaro Herrera PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"No necesitamos banderas
 No reconocemos fronteras"  (Jorge González)
>From 256904cc5a8718ac081dbf51f6263ab022e503f6 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera 
Date: Wed, 20 Apr 2022 23:26:28 +0200
Subject: [PATCH] Zstd

---
 doc/src/sgml/install-windows.sgml | 6 +++---
 doc/src/sgml/installation.sgml| 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml
index 43cc5f6f5b..104670d295 100644
--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
@@ -307,9 +307,9 @@ $ENV{MSBFLAGS}="/m";
 
 
 
- ZSTD
+ Zstd
  
-  Required for supporting ZSTD compression
+  Required for supporting Zstd compression
   method. Binaries and source can be downloaded from
   https://github.com/facebook/zstd/releases";>.
  
@@ -560,7 +560,7 @@ $ENV{PROVE_TESTS}='t/020*.pl t/010*.pl'
 
  ZSTD
  
-  Path to a zstd command. The default is
+  Path to a Zstd command. The default is
   zstd, which will search for a command by that
   name in the configured PATH.
  
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index df32025a86..c60484e221 100644
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -273,7 +273,7 @@ su - postgres
 
 
  
-  You need zstd, if you want to support
+  You need Zstd, if you want to support
   compression of data with that method; see
   .
   The minimum required version is 1.4.0.
@@ -996,7 +996,7 @@ build-postgresql:
--with-zstd

 
- Build with ZSTD compression support.
+ Build with Zstd compression support.
 

   
-- 
2.30.2

Re: typos

[Justin Pryzby]

On Wed, Apr 20, 2022 at 11:32:08PM +0200, Alvaro Herrera wrote:
> On 2022-Apr-19, Alvaro Herrera wrote:
> 
> > I propose we standardize on Zstd everywhere.
> > Users can look it up if they're really interested.
> 
> So the attached.
> 
> There are other uses of zstd, but those are referring to 
> the
> executable program.

This one shouldn't be changed, or not like this?

> @@ -560,7 +560,7 @@ $ENV{PROVE_TESTS}='t/020*.pl t/010*.pl'
>  
>   ZSTD
>   
> -  Path to a zstd command. The default is
> +  Path to a Zstd command. The default is
>zstd, which will search for a command by that
>name in the configured PATH.
>   

Maybe it should say s/a/the/, like:

-  Path to a zstd command. The default is
+  Path to the zstd command. The default is

Re: typos

[Amit Kapila]

On Wed, Apr 20, 2022 at 5:31 PM Alvaro Herrera  wrote:
>
> On 2022-Apr-20, Amit Kapila wrote:
>
> > Your proposed changes look good to me but I think all these places
> > need to mention 'column list' as well because the behavior is the same
> > for it.
>
> Hmm, you're right.  Added that, and changed the wording somewhat because
> some things read awkwardly.  Here's the result in patch form.
>

LGTM.

-- 
With Regards,
Amit Kapila.

Re: typos

[Michael Paquier]

On Wed, Apr 20, 2022 at 11:32:08PM +0200, Alvaro Herrera wrote:
> So the attached.
> 
> --- a/doc/src/sgml/install-windows.sgml
> +++ b/doc/src/sgml/install-windows.sgml
> @@ -307,9 +307,9 @@ $ENV{MSBFLAGS}="/m";
>  
>  
>  
> - ZSTD
> + Zstd
>   
> -  Required for supporting ZSTD compression
> +  Required for supporting Zstd compression

Looking at the zstd project itself for reference or just wiki-sensei,
I don't think that this is correct:
https://github.com/facebook/zstd
https://en.wikipedia.org/wiki/Zstd

Their README uses "zstd" in lower-case, while "Zstd" (first letter
upper-case) is used at the beginning of a sentence.
--
Michael


signature.asc
Description: PGP signature

Re: typos

[Peter Eisentraut]

On 21.04.22 06:36, Michael Paquier wrote:

On Wed, Apr 20, 2022 at 11:32:08PM +0200, Alvaro Herrera wrote:

So the attached.

--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
@@ -307,9 +307,9 @@ $ENV{MSBFLAGS}="/m";
  
  
  

- ZSTD
+ Zstd
   
-  Required for supporting ZSTD compression
+  Required for supporting Zstd compression


Looking at the zstd project itself for reference or just wiki-sensei,
I don't think that this is correct:
https://github.com/facebook/zstd
https://en.wikipedia.org/wiki/Zstd

Their README uses "zstd" in lower-case, while "Zstd" (first letter
upper-case) is used at the beginning of a sentence.


It is referred to as "Zstandard" at both of those places.  Maybe we 
should use that.  That is also easier to pronounce.

Re: typos

[Alvaro Herrera]

On 2022-Apr-21, Peter Eisentraut wrote:

> It is referred to as "Zstandard" at both of those places.  Maybe we should
> use that.  That is also easier to pronounce.

Yeah, I looked at other places (such as Yann Collet's blog) and I agree
that Zstandard seems to be the accepted spelling of the product.  Pushed
that way.

-- 
Álvaro HerreraBreisgau, Deutschland  —  https://www.EnterpriseDB.com/
Tom: There seems to be something broken here.
Teodor: I'm in sackcloth and ashes...  Fixed.
http://archives.postgresql.org/message-id/482d1632.8010...@sigaev.ru

Re: typos

[Justin Pryzby]

I found a bunch more typos; a couple from codespell, and several which are the
result of looking for previously-reported typos, like:

time git log origin --grep '[tT]ypo' --word-diff -U1 |grep -Eo 
'\[-[[:lower:]]+-\]' |sed 's/^\[-//; s/-\]$//' |sort -u |grep -Fxvwf 
/usr/share/dict/words >badwords.txt
time grep -rhoFwf badwords.txt doc |sort -u >not-badwords.txt
time grep -Fxvwf not-badwords.txt ./badwords.txt >./badwords.txt.new
time grep -rhoIFwf ./badwords.txt.new src --incl='*.[chly]' --incl='*.p[lm]' 
|sort |uniq -c |sort -nr |less

>From 2166aa51840094f4b738f4a9af1ad6bd94a97cff Mon Sep 17 00:00:00 2001
From: Justin Pryzby 
Date: Mon, 18 Apr 2022 10:13:09 -0500
Subject: [PATCH v2022051001 1/2] doc: ANDed and ORed

---
 doc/src/sgml/indexam.sgml | 2 +-
 doc/src/sgml/indices.sgml | 4 ++--
 doc/src/sgml/logical-replication.sgml | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/src/sgml/indexam.sgml b/doc/src/sgml/indexam.sgml
index d4163c96e9f..16669f4086a 100644
--- a/doc/src/sgml/indexam.sgml
+++ b/doc/src/sgml/indexam.sgml
@@ -843,7 +843,7 @@ amparallelrescan (IndexScanDesc scan);
constant, where the index key is one of the columns of the
index and the operator is one of the members of the operator family
associated with that index column.  An index scan has zero or more scan
-   keys, which are implicitly ANDed — the returned tuples are expected
+   keys, which are implicitly AND-ed — the returned tuples are expected
to satisfy all the indicated conditions.
   
 
diff --git a/doc/src/sgml/indices.sgml b/doc/src/sgml/indices.sgml
index 023157d8884..890c6d3451c 100644
--- a/doc/src/sgml/indices.sgml
+++ b/doc/src/sgml/indices.sgml
@@ -597,7 +597,7 @@ CREATE INDEX test3_desc_index ON test3 (id DESC NULLS LAST);
a query like WHERE x = 42 OR x = 47 OR x = 53 OR x = 99
could be broken down into four separate scans of an index on x,
each scan using one of the query clauses.  The results of these scans are
-   then ORed together to produce the result.  Another example is that if we
+   then OR-ed together to produce the result.  Another example is that if we
have separate indexes on x and y, one possible
implementation of a query like WHERE x = 5 AND y = 6 is to
use each index with the appropriate query clause and then AND together
@@ -608,7 +608,7 @@ CREATE INDEX test3_desc_index ON test3 (id DESC NULLS LAST);
To combine multiple indexes, the system scans each needed index and
prepares a bitmap in memory giving the locations of
table rows that are reported as matching that index's conditions.
-   The bitmaps are then ANDed and ORed together as needed by the query.
+   The bitmaps are then AND-ed and OR-ed together as needed by the query.
Finally, the actual table rows are visited and returned.  The table rows
are visited in physical order, because that is how the bitmap is laid
out; this means that any ordering of the original indexes is lost, and
diff --git a/doc/src/sgml/logical-replication.sgml b/doc/src/sgml/logical-replication.sgml
index 145ea71d61b..d2939fec71c 100644
--- a/doc/src/sgml/logical-replication.sgml
+++ b/doc/src/sgml/logical-replication.sgml
@@ -477,7 +477,7 @@

 If the subscription has several publications in which the same table has
 been published with different row filters (for the same publish
-operation), those expressions get ORed together, so that rows satisfying
+operation), those expressions get OR-ed together, so that rows satisfying
 any of the expressions will be replicated. This means all
 the other row filters for the same table become redundant if:
 
-- 
2.17.1

>From a566141ebb01fc48cb766339553b600755ca4dca Mon Sep 17 00:00:00 2001
From: Justin Pryzby 
Date: Tue, 10 May 2022 19:02:02 -0500
Subject: [PATCH v2022051001 2/2] typos

---
 contrib/citext/expected/citext.out  | 2 +-
 contrib/citext/expected/citext_1.out| 2 +-
 contrib/citext/sql/citext.sql   | 2 +-
 src/backend/executor/execGrouping.c | 2 +-
 src/backend/parser/parse_expr.c | 2 +-
 src/backend/replication/basebackup_target.c | 2 +-
 src/backend/utils/adt/int8.c| 2 +-
 src/bin/pg_basebackup/bbstreamer_tar.c  | 2 +-
 src/bin/pg_rewind/t/007_standby_source.pl   | 2 +-
 src/bin/pg_rewind/t/009_growing_files.pl| 2 +-
 src/test/regress/expected/psql.out  | 2 +-
 src/test/regress/sql/psql.sql   | 2 +-
 src/test/ssl/t/SSL/Backend/OpenSSL.pm   | 2 +-
 13 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/contrib/citext/expected/citext.out b/contrib/citext/expected/citext.out
index 5afcc50920e..1c555981363 100644
--- a/contrib/citext/expected/citext.out
+++ b/contrib/citext/expected/citext.out
@@ -2270,7 +2270,7 @@ SELECT COUNT(*) = 8::bigint AS t FROM try;
 
 INSERT INTO try
 VALUES ( to_char(  now()::timestamp,  'HH12:MI:SS') ),
-   ( to_char(  now() + '1 se

Re: typos

[Michael Paquier]

On Tue, May 10, 2022 at 09:03:34PM -0500, Justin Pryzby wrote:
> I found a bunch more typos; a couple from codespell, and several which are the
> result of looking for previously-reported typos, like:

Thanks, applied 0002.

Regarding 0001, I don't really know which one of {AND,OR}ed or
{AND,OR}-ed is better.  Note that the code prefers the former, but
your patch changes the docs to use the latter.
--
Michael


signature.asc
Description: PGP signature

Re: typos (and more)

[Justin Pryzby]

On Fri, Sep 24, 2021 at 04:58:27PM -0500, Justin Pryzby wrote:
> A compilation of fixes for master.

Thanks Michael for applying fixes to user-facing docs (I hadn't realized that
the 2nd one needed to be backpatched).

This fixes an file I failed to include in the "recheck" patch and more typos
for extended stats (+Tomas).

+Andres (Jit), +Zhihong (file header comments).
>From b244c10676210b096e03a4170b5ce106fc470457 Mon Sep 17 00:00:00 2001
From: Justin Pryzby 
Date: Wed, 28 Apr 2021 14:12:49 -0500
Subject: [PATCH v2 01/12] Avoid double parens

git grep -l '\https://www.postgresql.org/message-id/flat/20210428182936.ge27...@telsasoft.com
---
 contrib/amcheck/verify_heapam.c  | 6 +++---
 contrib/ltree/ltree_io.c | 6 +++---
 src/backend/access/transam/xact.c| 6 +++---
 src/backend/commands/tablecmds.c | 2 +-
 src/backend/nodes/nodeFuncs.c| 4 ++--
 src/backend/replication/logical/decode.c | 2 +-
 6 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/contrib/amcheck/verify_heapam.c b/contrib/amcheck/verify_heapam.c
index 173f99d787..0ac52b6ba2 100644
--- a/contrib/amcheck/verify_heapam.c
+++ b/contrib/amcheck/verify_heapam.c
@@ -406,13 +406,13 @@ verify_heapam(PG_FUNCTION_ARGS)
 	   &vmbuffer);
 			if (skip_option == SKIP_PAGES_ALL_FROZEN)
 			{
-if ((mapbits & VISIBILITYMAP_ALL_FROZEN) != 0)
+if (mapbits & VISIBILITYMAP_ALL_FROZEN)
 	continue;
 			}
 
 			if (skip_option == SKIP_PAGES_ALL_VISIBLE)
 			{
-if ((mapbits & VISIBILITYMAP_ALL_VISIBLE) != 0)
+if (mapbits & VISIBILITYMAP_ALL_VISIBLE)
 	continue;
 			}
 		}
@@ -690,7 +690,7 @@ check_tuple_header(HeapCheckContext *ctx)
 			report_corruption(ctx,
 			  psprintf("tuple data should begin at byte %u, but actually begins at byte %u (1 attribute, has nulls)",
 	   expected_hoff, ctx->tuphdr->t_hoff));
-		else if ((infomask & HEAP_HASNULL))
+		else if (infomask & HEAP_HASNULL)
 			report_corruption(ctx,
 			  psprintf("tuple data should begin at byte %u, but actually begins at byte %u (%u attributes, has nulls)",
 	   expected_hoff, ctx->tuphdr->t_hoff, ctx->natts));
diff --git a/contrib/ltree/ltree_io.c b/contrib/ltree/ltree_io.c
index 15115cb29f..b75f35d5b5 100644
--- a/contrib/ltree/ltree_io.c
+++ b/contrib/ltree/ltree_io.c
@@ -661,17 +661,17 @@ deparse_lquery(const lquery *in)
 }
 memcpy(ptr, curtlevel->name, curtlevel->len);
 ptr += curtlevel->len;
-if ((curtlevel->flag & LVAR_SUBLEXEME))
+if (curtlevel->flag & LVAR_SUBLEXEME)
 {
 	*ptr = '%';
 	ptr++;
 }
-if ((curtlevel->flag & LVAR_INCASE))
+if (curtlevel->flag & LVAR_INCASE)
 {
 	*ptr = '@';
 	ptr++;
 }
-if ((curtlevel->flag & LVAR_ANYEND))
+if (curtlevel->flag & LVAR_ANYEND)
 {
 	*ptr = '*';
 	ptr++;
diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c
index 6597ec45a9..8350a8fd19 100644
--- a/src/backend/access/transam/xact.c
+++ b/src/backend/access/transam/xact.c
@@ -2427,7 +2427,7 @@ PrepareTransaction(void)
 	 * cases, such as a temp table created and dropped all within the
 	 * transaction.  That seems to require much more bookkeeping though.
 	 */
-	if ((MyXactFlags & XACT_FLAGS_ACCESSEDTEMPNAMESPACE))
+	if (MyXactFlags & XACT_FLAGS_ACCESSEDTEMPNAMESPACE)
 		ereport(ERROR,
 (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
  errmsg("cannot PREPARE a transaction that has operated on temporary objects")));
@@ -5540,7 +5540,7 @@ XactLogCommitRecord(TimestampTz commit_time,
 		xl_xinfo.xinfo |= XACT_COMPLETION_UPDATE_RELCACHE_FILE;
 	if (forceSyncCommit)
 		xl_xinfo.xinfo |= XACT_COMPLETION_FORCE_SYNC_COMMIT;
-	if ((xactflags & XACT_FLAGS_ACQUIREDACCESSEXCLUSIVELOCK))
+	if (xactflags & XACT_FLAGS_ACQUIREDACCESSEXCLUSIVELOCK)
 		xl_xinfo.xinfo |= XACT_XINFO_HAS_AE_LOCKS;
 
 	/*
@@ -5691,7 +5691,7 @@ XactLogAbortRecord(TimestampTz abort_time,
 
 	xlrec.xact_time = abort_time;
 
-	if ((xactflags & XACT_FLAGS_ACQUIREDACCESSEXCLUSIVELOCK))
+	if (xactflags & XACT_FLAGS_ACQUIREDACCESSEXCLUSIVELOCK)
 		xl_xinfo.xinfo |= XACT_XINFO_HAS_AE_LOCKS;
 
 	if (nsubxacts > 0)
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index dbee6ae199..e018cdfd9e 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -16309,7 +16309,7 @@ PreCommit_on_commit_actions(void)
  * relations, we can skip truncating ON COMMIT DELETE ROWS
  * tables, as they must still be empty.
  */
-if ((MyXactFlags & XACT_FLAGS_ACCESSEDTEMPNAMESPACE))
+if (MyXactFlags & XACT_FLAGS_ACCESSEDTEMPNAMESPACE)
 	oids_to_truncate = lappend_oid(oids_to_truncate, oc->relid);
 break;
 			case ONCOMMIT_DROP:
diff --git a/src/backend/nodes/nodeFuncs.c b/src/backend/nodes/nodeFuncs.c
index e276264882..e5e82cb85f 100644
--- a/src/backend/nodes/nodeFuncs.c
+++ b/src/backend/nodes/nodeFuncs.c
@@ -2390,7 +2390,7 @@ query_tree_walker(Query *query,

Re: typos (and more)

[Michael Paquier]

On Sun, Sep 26, 2021 at 12:01:17PM -0500, Justin Pryzby wrote:
> Thanks Michael for applying fixes to user-facing docs (I hadn't realized that
> the 2nd one needed to be backpatched).

Yes, thanks for compiling all these.  The two changes committed were
the only user-visible changes, which is why I have hastened this part
to include those fixes.  The rest could just go on HEAD.
--
Michael


signature.asc
Description: PGP signature

Re: typos (and more)

[Michael Paquier]

On Mon, Sep 27, 2021 at 09:24:27AM +0900, Michael Paquier wrote:
> Yes, thanks for compiling all these.  The two changes committed were
> the only user-visible changes, which is why I have hastened this part
> to include those fixes.  The rest could just go on HEAD.

I have looked at the full set, and applied 0003, 0006, 0009, 0010 and
0011.  0001 has been discussed separately, and I am really not sure if
that's worth bothering.  0002 may actually break some code?  I have
let 0004 and 0005 alone.  0007 could be related to the discussion
where we could just remove all those IDENTIFICATION fields.  The use
of "statistic", "statistics" and "statistics object" in 0008 and 0012
is indeed inconsistent.  The latter term is the most used, but it
sounds a bit weird to me even if it refers to the DDL object
manipulated.  Simply using "statistics" would be tempting.
--
Michael


signature.asc
Description: PGP signature

Re: typos (and more)

[Alvaro Herrera]

On 2021-Sep-27, Michael Paquier wrote:

> The use
> of "statistic", "statistics" and "statistics object" in 0008 and 0012
> is indeed inconsistent.  The latter term is the most used, but it
> sounds a bit weird to me even if it refers to the DDL object
> manipulated.  Simply using "statistics" would be tempting.

Initially we just used "statistic" as a noun, which IIRC was already
grammatically wrong (but I didn't know that and I think Tomas didn't
either); later at some point when discussing how to use that noun in
plural we realized this and argued that merely using "statistics" was
even more wrong.  It was then that we started using the term "statistics
object" with plural "statistics objects".  Going back to using just
"statistics" is unlikely to have become correct; I think Justin's
patches 0008 and 0012 are correct.

-- 
Álvaro Herrera   39°49'30"S 73°17'W  —  https://www.EnterpriseDB.com/
"La libertad es como el dinero; el que no la sabe emplear la pierde" (Alvarez)

Re: typos (and more)

[Michael Paquier]

On Mon, Sep 27, 2021 at 06:04:02PM -0300, Alvaro Herrera wrote:
> Initially we just used "statistic" as a noun, which IIRC was already
> grammatically wrong (but I didn't know that and I think Tomas didn't
> either); later at some point when discussing how to use that noun in
> plural we realized this and argued that merely using "statistics" was
> even more wrong.  It was then that we started using the term "statistics
> object" with plural "statistics objects".  Going back to using just
> "statistics" is unlikely to have become correct; I think Justin's
> patches 0008 and 0012 are correct.

Thanks for confirming.

 if (list_length(pstate->p_rtable) != 1)
 ereport(ERROR,
 (errcode(ERRCODE_INVALID_COLUMN_REFERENCE),
- errmsg("statistics expressions can refer only to the table 
being indexed")));
+ errmsg("statistics expressions can refer only to the table 
being referenced")));
This part should be backpatched?  The code claims that this should
be dead code so an elog() would be more adapted, and the same can be
said about transformRuleStmt() and transformIndexStmt(), no?  That
would be less messages to translate. 
--
Michael


signature.asc
Description: PGP signature

Re: typos (and more)

[Justin Pryzby]

On Mon, Sep 27, 2021 at 06:04:02PM -0300, Alvaro Herrera wrote:
> On 2021-Sep-27, Michael Paquier wrote:
> 
> > The use
> > of "statistic", "statistics" and "statistics object" in 0008 and 0012
> > is indeed inconsistent.  The latter term is the most used, but it
> > sounds a bit weird to me even if it refers to the DDL object
> > manipulated.  Simply using "statistics" would be tempting.
> 
> Initially we just used "statistic" as a noun, which IIRC was already
> grammatically wrong (but I didn't know that and I think Tomas didn't
> either); later at some point when discussing how to use that noun in
> plural we realized this and argued that merely using "statistics" was
> even more wrong.  It was then that we started using the term "statistics
> object" with plural "statistics objects".  Going back to using just
> "statistics" is unlikely to have become correct; I think Justin's
> patches 0008 and 0012 are correct.

Attached is an updated patch fixing more of the same.

-- 
Justin
>From 45c16e1cb6b3ddf007806f5942f3acf64a75edf7 Mon Sep 17 00:00:00 2001
From: Justin Pryzby 
Date: Sun, 12 Sep 2021 23:45:05 -0500
Subject: [PATCH] Refer to plural statistics OBJECTS

See also: f04c9a61468904b6815b2bc73a48878817766e0e
---
 src/backend/commands/statscmds.c| 14 +++---
 src/backend/statistics/extended_stats.c | 12 ++--
 src/backend/utils/adt/selfuncs.c| 12 ++--
 3 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/src/backend/commands/statscmds.c b/src/backend/commands/statscmds.c
index 9938b65083..13987d9dcb 100644
--- a/src/backend/commands/statscmds.c
+++ b/src/backend/commands/statscmds.c
@@ -431,7 +431,7 @@ CreateStatistics(CreateStatsStmt *stmt)
 	 * similar to why we don't bother with extracting columns from
 	 * expressions. It's either expensive or very easy to defeat for
 	 * determined user, and there's no risk if we allow such statistics (the
-	 * statistics is useless, but harmless).
+	 * statistic is useless, but harmless).
 	 */
 	foreach(cell, stxexprs)
 	{
@@ -560,7 +560,7 @@ CreateStatistics(CreateStatsStmt *stmt)
 	}
 
 	/*
-	 * If there are no dependencies on a column, give the statistics an auto
+	 * If there are no dependencies on a column, give the statistics object an auto
 	 * dependency on the whole table.  In most cases, this will be redundant,
 	 * but it might not be if the statistics expressions contain no Vars
 	 * (which might seem strange but possible). This is consistent with what
@@ -649,7 +649,7 @@ AlterStatistics(AlterStatsStmt *stmt)
 	stxoid = get_statistics_object_oid(stmt->defnames, stmt->missing_ok);
 
 	/*
-	 * If we got here and the OID is not valid, it means the statistics does
+	 * If we got here and the OID is not valid, it means the statistics object does
 	 * not exist, but the command specified IF EXISTS. So report this as a
 	 * simple NOTICE and we're done.
 	 */
@@ -768,7 +768,7 @@ RemoveStatisticsById(Oid statsOid)
 }
 
 /*
- * Select a nonconflicting name for a new statistics.
+ * Select a nonconflicting name for a new statistics object.
  *
  * name1, name2, and label are used the same way as for makeObjectName(),
  * except that the label can't be NULL; digits will be appended to the label
@@ -815,7 +815,7 @@ ChooseExtendedStatisticName(const char *name1, const char *name2,
 }
 
 /*
- * Generate "name2" for a new statistics given the list of column names for it
+ * Generate "name2" for a new statistics object given the list of column names for it
  * This will be passed to ChooseExtendedStatisticName along with the parent
  * table name and a suitable label.
  *
@@ -869,8 +869,8 @@ ChooseExtendedStatisticNameAddition(List *exprs)
 }
 
 /*
- * StatisticsGetRelation: given a statistics's relation OID, get the OID of
- * the relation it is an statistics on.  Uses the system cache.
+ * StatisticsGetRelation: given a statistics object's OID, get the OID of
+ * the relation it is defined on.  Uses the system cache.
  */
 Oid
 StatisticsGetRelation(Oid statId, bool missing_ok)
diff --git a/src/backend/statistics/extended_stats.c b/src/backend/statistics/extended_stats.c
index 4c35223457..97f4ba3590 100644
--- a/src/backend/statistics/extended_stats.c
+++ b/src/backend/statistics/extended_stats.c
@@ -182,7 +182,7 @@ BuildRelationExtStatistics(Relation onerel, double totalrows,
 			continue;
 		}
 
-		/* compute statistics target for this statistics */
+		/* compute statistics target for this statistics object */
 		stattarget = statext_compute_stattarget(stat->stattarget,
 bms_num_members(stat->columns),
 stats);
@@ -195,7 +195,7 @@ BuildRelationExtStatistics(Relation onerel, double totalrows,
 		if (stattarget == 0)
 			continue;
 
-		/* evaluate expressions (if the statistics has any) */
+		/* evaluate expressions (if the statistics object has any) */
 		data = make_build_data(onerel, stat, numrows, rows, stats, stattarget);
 
 		/* compute statistic of each requested type */
@@ -257,7 +257

Re: typos (and more)

[Michael Paquier]

On Mon, Sep 27, 2021 at 07:50:02PM -0500, Justin Pryzby wrote:
> Attached is an updated patch fixing more of the same.

Does this include everything you have spotted, as well as everything
from the previous patches 0008 and 0012 posted?
--
Michael


signature.asc
Description: PGP signature

Re: typos (and more)

[Justin Pryzby]

On Tue, Sep 28, 2021 at 11:15:39AM +0900, Michael Paquier wrote:
> On Mon, Sep 27, 2021 at 07:50:02PM -0500, Justin Pryzby wrote:
> > Attached is an updated patch fixing more of the same.
> 
> Does this include everything you have spotted, as well as everything
> from the previous patches 0008 and 0012 posted?

That's an "expanded" version of 0008.

It doesn't include 0012, which is primarily about fixing incorrect references
to "index expressions" that should refer to stats expressions.  Naturally 0012
also uses the phrase "statistics objects", and fixes one nearby reference
that's not itself about indexes, which could arguably be in 0008 instead..

-- 
Justin

Re: typos (and more)

[Michael Paquier]

On Mon, Sep 27, 2021 at 09:27:56PM -0500, Justin Pryzby wrote:
> That's an "expanded" version of 0008.

Okay, thanks.

> It doesn't include 0012, which is primarily about fixing incorrect references
> to "index expressions" that should refer to stats expressions.  Naturally 0012
> also uses the phrase "statistics objects", and fixes one nearby reference
> that's not itself about indexes, which could arguably be in 0008 instead..

Merging both made the most sense to me after reviewing the whole area
of the code dedicated to stats.  This has been applied after taking
care of some issues with the indentation, with few extra tweaks.
--
Michael


signature.asc
Description: PGP signature

Re: Typos in reorderbuffer.c.

[Amit Kapila]

On Thu, Mar 14, 2024 at 9:58 AM Kyotaro Horiguchi
 wrote:
>
> While examining reorderbuffer.c, I found several typos. I'm not sure
> if fixing them is worthwhile, but I've attached a fix just in case.
>

LGTM. I'll push this in some time.

-- 
With Regards,
Amit Kapila.

Re: Typos in reorderbuffer.c.

[Kyotaro Horiguchi]

At Thu, 14 Mar 2024 11:23:38 +0530, Amit Kapila  wrote 
in 
> On Thu, Mar 14, 2024 at 9:58 AM Kyotaro Horiguchi
>  wrote:
> >
> > While examining reorderbuffer.c, I found several typos. I'm not sure
> > if fixing them is worthwhile, but I've attached a fix just in case.
> >
> 
> LGTM. I'll push this in some time.

Thanks!

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Re: Typos from Covering Index patch

[Heikki Linnakangas]

On 11/04/18 03:52, Michael Paquier wrote:

Hi all,

I am catching up with new features so I have begun going through
Covering indexes.  While reading the code, I have noticed a couple of
things:
1) Some typos.
2) An inconsistent variable name in pg_dump.


Committed, thanks!

- Heikki

Re: Typos from Covering Index patch

[Heikki Linnakangas]

On 11/04/18 03:52, Michael Paquier wrote:

Hi all,

I am catching up with new features so I have begun going through
Covering indexes.  While reading the code, I have noticed a couple of
things:
1) Some typos.
2) An inconsistent variable name in pg_dump.


Committed, thanks!

- Heikki

Re: Typos from Covering Index patch

[Michael Paquier]

On Tue, Apr 17, 2018 at 11:57:20AM -0400, Heikki Linnakangas wrote:
> Committed, thanks!

Thanks, Heikki.
--
Michael


signature.asc
Description: PGP signature

Re: Typos from Covering Index patch

[Heikki Linnakangas]

On 11/04/18 03:52, Michael Paquier wrote:

Hi all,

I am catching up with new features so I have begun going through
Covering indexes.  While reading the code, I have noticed a couple of
things:
1) Some typos.
2) An inconsistent variable name in pg_dump.


Committed, thanks!

- Heikki

Re: Typos from Covering Index patch

[Heikki Linnakangas]

On 11/04/18 03:52, Michael Paquier wrote:

Hi all,

I am catching up with new features so I have begun going through
Covering indexes.  While reading the code, I have noticed a couple of
things:
1) Some typos.
2) An inconsistent variable name in pg_dump.


Committed, thanks!

- Heikki

Re: Typos from Covering Index patch

[Michael Paquier]

On Tue, Apr 17, 2018 at 11:57:20AM -0400, Heikki Linnakangas wrote:
> Committed, thanks!

Thanks, Heikki.
--
Michael


signature.asc
Description: PGP signature

Re: Typos and inconsistencies in code

[Dilip Kumar]

On Mon, Oct 28, 2019 at 11:22 PM vignesh C  wrote:
>
> Hi,
>
> Please find the attached patch having the fix for the typos and
> inconsistencies present in code.
> The patch contains the following changes:
> 1) attibute -> attribute
> 2) efficent -> efficient
> 3) becuase -> because
> 4) fallthru -> fall through
> 5) uncoming -> upcoming
> 6) ans -> and
> 7) requrested -> requested
> 8) peforming -> performing
> 9) heartbearts -> heartbeats
> 10) parametrizing -> parameterizing
> 11) uninit -> uninitialized
> 12) bufgr  -> bufmgr
> 13) directi -> direct
> 14) thead -> thread
> 15) somthing -> something
> 16) freek -> freak
> 17) changesd -> changes
>
> Let me know your thoughts on the same.
>

Few comments:
1.
  * The act of allocating pages to recycle may have invalidated the
- * results of our previous btree reserch, so repeat it. (We could
+ * results of our previous btree search, so repeat it. (We could
  * recheck whether any of our split-avoidance strategies that were

I think the old comment meant "btree research" but you changed to "btree search"

2.
 /* copy&pasted from .../src/backend/utils/adt/datetime.c
- * and changesd struct pg_tm to struct tm
+ * and changes struct pg_tm to struct tm
  */
Seems like this comment meant "Changed struct pg_tm to struct tm"

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

Re: Typos and inconsistencies in code

[vignesh C]

On Tue, Oct 29, 2019 at 9:19 AM Dilip Kumar  wrote:
>
> Few comments:
> 1.
>   * The act of allocating pages to recycle may have invalidated the
> - * results of our previous btree reserch, so repeat it. (We could
> + * results of our previous btree search, so repeat it. (We could
>   * recheck whether any of our split-avoidance strategies that were
>
Fixed
> I think the old comment meant "btree research" but you changed to "btree 
> search"
>
> 2.
>  /* copy&pasted from .../src/backend/utils/adt/datetime.c
> - * and changesd struct pg_tm to struct tm
> + * and changes struct pg_tm to struct tm
>   */
> Seems like this comment meant "Changed struct pg_tm to struct tm"
Fixed
Thanks for the review.
I have attached the updated patch with the fixes.

Regards,
Vignesh
EnterpriseDB: http://www.enterprisedb.com
From dd0ef8c36011095508937f31890690608697d30d Mon Sep 17 00:00:00 2001
From: vignesh 
Date: Tue, 29 Oct 2019 17:16:57 +0530
Subject: [PATCH] Fixed typos in the code.

Fixed typos across the code.
---
 contrib/pg_trgm/trgm_op.c |  4 ++--
 contrib/pgcrypto/imath.c  |  4 ++--
 contrib/pgcrypto/pgp-info.c   |  2 +-
 contrib/sepgsql/database.c|  2 +-
 contrib/sepgsql/dml.c |  2 +-
 contrib/sepgsql/schema.c  |  2 +-
 src/backend/access/common/detoast.c   |  2 +-
 src/backend/access/nbtree/nbtsplitloc.c   |  2 +-
 src/backend/replication/walreceiver.c |  2 +-
 src/backend/statistics/mcv.c  |  2 +-
 src/backend/storage/buffer/bufmgr.c   |  4 +++-
 src/backend/storage/lmgr/proc.c   |  2 +-
 src/backend/storage/lmgr/s_lock.c |  2 +-
 src/backend/utils/adt/jsonfuncs.c |  2 +-
 src/backend/utils/adt/rangetypes_gist.c   |  6 +++---
 src/backend/utils/mmgr/freepage.c |  2 +-
 src/bin/pg_upgrade/parallel.c |  2 +-
 src/bin/psql/tab-complete.c   |  2 +-
 src/interfaces/ecpg/compatlib/informix.c  |  2 +-
 src/interfaces/ecpg/pgtypeslib/interval.c | 10 +-
 20 files changed, 30 insertions(+), 28 deletions(-)

diff --git a/contrib/pg_trgm/trgm_op.c b/contrib/pg_trgm/trgm_op.c
index 4679efe..07a3180 100644
--- a/contrib/pg_trgm/trgm_op.c
+++ b/contrib/pg_trgm/trgm_op.c
@@ -467,7 +467,7 @@ comp_ptrgm(const void *v1, const void *v2)
  * ulen1: count of unique trigrams of array "trg1".
  * len2: length of array "trg2" and array "trg2indexes".
  * len: length of the array "found".
- * lags: set of boolean flags parametrizing similarity calculation.
+ * lags: set of boolean flags parameterizing similarity calculation.
  * bounds: whether each trigram is left/right bound of word.
  *
  * Returns word similarity.
@@ -632,7 +632,7 @@ iterate_word_similarity(int *trg2indexes,
  *
  * str1: search pattern string, of length slen1 bytes.
  * str2: text in which we are looking for a word, of length slen2 bytes.
- * flags: set of boolean flags parametrizing similarity calculation.
+ * flags: set of boolean flags parameterizing similarity calculation.
  *
  * Returns word similarity.
  */
diff --git a/contrib/pgcrypto/imath.c b/contrib/pgcrypto/imath.c
index 545f148..ac250c7 100644
--- a/contrib/pgcrypto/imath.c
+++ b/contrib/pgcrypto/imath.c
@@ -3366,14 +3366,14 @@ s_udiv_knuth(mp_int u, mp_int v)
 		 * D4,D5,D6: Multiply qhat * v and test for a correct value of q
 		 *
 		 * We proceed a bit different than the way described by Knuth. This
-		 * way is simpler but less efficent. Instead of doing the multiply and
+		 * way is simpler but less efficient. Instead of doing the multiply and
 		 * subtract then checking for underflow, we first do the multiply of
 		 * qhat * v and see if it is larger than the current remainder r. If
 		 * it is larger, we decrease qhat by one and try again. We may need to
 		 * decrease qhat one more time before we get a value that is smaller
 		 * than r.
 		 *
-		 * This way is less efficent than Knuth becuase we do more multiplies,
+		 * This way is less efficient than Knuth because we do more multiplies,
 		 * but we do not need to worry about underflow this way.
 		 */
 		/* t = qhat * v */
diff --git a/contrib/pgcrypto/pgp-info.c b/contrib/pgcrypto/pgp-info.c
index b2300ea..83dc604 100644
--- a/contrib/pgcrypto/pgp-info.c
+++ b/contrib/pgcrypto/pgp-info.c
@@ -169,7 +169,7 @@ pgp_get_keyid(MBuf *pgp_data, char *dst)
 break;
 			case PGP_PKT_SYMENCRYPTED_SESSKEY:
 got_symenc_key++;
-/* fallthru */
+/* fall through */
 			case PGP_PKT_SIGNATURE:
 			case PGP_PKT_MARKER:
 			case PGP_PKT_TRUST:
diff --git a/contrib/sepgsql/database.c b/contrib/sepgsql/database.c
index 0190d38..5850e07 100644
--- a/contrib/sepgsql/database.c
+++ b/contrib/sepgsql/database.c
@@ -74,7 +74,7 @@ sepgsql_database_post_create(Oid databaseId, const char *dtemplate)
 	 * Compute a default security label of the newly created database based on
 	 * a pair of security label of client and source database.
 	 *
-	 * XXX - uncoming version of lib

Re: Typos and inconsistencies in code

[Michael Paquier]

On Tue, Oct 29, 2019 at 05:27:20PM +0530, vignesh C wrote:
> I have attached the updated patch with the fixes.

The changes in rangetypes_gist.c are not correct, the usual pattern to
add an "s" after the structure name is quite common when referring to
multiple elements.  We could perhaps use "put-your-struct entries"
instead, but I have seen the pattern of HEAD quite a lot as well (see
also for example mcv.c with SortItem that is a file your patch
touches).

A comment indentation was wrong in detoast.c, not the fault of this
patch but I have fixed it at the same time.

Note: there is room for refactoring in pgtypeslib with the pg_tm/tm
business..

The fixes in imath.c had better be submitted in upstream:
https://github.com/creachadair/imath/blob/v1.29/imath.c
So I have raised an issue here:
https://github.com/creachadair/imath/issues/43
--
Michael


signature.asc
Description: PGP signature

Re: Typos and inconsistencies in code

[vignesh C]

On Wed, Oct 30, 2019 at 6:35 AM Michael Paquier  wrote:
>
> On Tue, Oct 29, 2019 at 05:27:20PM +0530, vignesh C wrote:
> > I have attached the updated patch with the fixes.
>
> The changes in rangetypes_gist.c are not correct, the usual pattern to
> add an "s" after the structure name is quite common when referring to
> multiple elements.  We could perhaps use "put-your-struct entries"
> instead, but I have seen the pattern of HEAD quite a lot as well (see
> also for example mcv.c with SortItem that is a file your patch
> touches).
>
> A comment indentation was wrong in detoast.c, not the fault of this
> patch but I have fixed it at the same time.
>
Thanks for pushing the changes Michael.

Regards,
Vignesh
EnterpriseDB: http://www.enterprisedb.com

Re: Typos and wording in jsonpath-exec.c

[Magnus Hagander]

On Tue, May 7, 2019 at 2:39 PM Daniel Gustafsson  wrote:

> Spotted two minor typos when skimming through code, and a sentence on
> returnvalue which seemed a bit odd since executeJsonPath() can exit on
> ereport().  The attached diff fixes the typos and suggests a new wording.
>

Pushed. Thanks!

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ 
 Work: https://www.redpill-linpro.com/ 

Re: Typos and wording in jsonpath-exec.c

[Magnus Hagander]

On Tue, May 7, 2019 at 2:39 PM Daniel Gustafsson  wrote:

> Spotted two minor typos when skimming through code, and a sentence on
> returnvalue which seemed a bit odd since executeJsonPath() can exit on
> ereport().  The attached diff fixes the typos and suggests a new wording.
>

Pushed. Thanks!

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ 
 Work: https://www.redpill-linpro.com/ 

Re: typos in comments referring to macros

[Amit Kapila]

On Wed, Jun 10, 2020 at 2:47 PM John Naylor  wrote:
>
> It should be BLCKSZ and LOBLKSIZE, as in the attached.
>

LGTM on first look. I'll push either later today or tomorrow.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Re: typos in comments referring to macros

[Amit Kapila]

On Wed, Jun 10, 2020 at 3:19 PM Amit Kapila  wrote:
>
> On Wed, Jun 10, 2020 at 2:47 PM John Naylor  
> wrote:
> >
> > It should be BLCKSZ and LOBLKSIZE, as in the attached.
> >
>
> LGTM on first look. I'll push either later today or tomorrow.
>

Pushed.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Re: typos in comments and user docs

[Amit Kapila]

On Thu, Feb 6, 2020 at 7:44 AM Justin Pryzby  wrote:
>
> I sent earlier version of this a few times last year along with bunch of other
> doc patches but it was never picked up.  So maybe I'll try send one at a time
> in more digestible chunks.
> https://www.postgresql.org/message-id/flat/20190427025647.GD3925%40telsasoft.com#e1731c33455145eadc1158042cc411f9
>
> From cb5842724330dfcfc914f2e3effdbfe4843be565 Mon Sep 17 00:00:00 2001
> From: Justin Pryzby 
> Date: Thu, 9 May 2019 21:13:55 -0500
> Subject: [PATCH] spelling and typos
>
> ---
>  doc/src/sgml/bloom.sgml| 2 +-
>  doc/src/sgml/config.sgml   | 2 +-
>  doc/src/sgml/ref/alter_table.sgml  | 2 +-
>  doc/src/sgml/sources.sgml  | 4 ++--
>  src/backend/access/transam/README.parallel | 2 +-
>  src/backend/storage/buffer/bufmgr.c| 2 +-
>  src/backend/storage/sync/sync.c| 2 +-
>  src/include/access/tableam.h   | 2 +-
>  8 files changed, 9 insertions(+), 9 deletions(-)
>

Your changes look fine to me on the first read.  I will push this to
HEAD unless there are any objections.   If we want them in
back-branches, we might want to probably segregate the changes based
on the branch until those apply.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Re: typos in comments and user docs

[Michael Paquier]

On Thu, Feb 06, 2020 at 08:47:14AM +0530, Amit Kapila wrote:
> Your changes look fine to me on the first read.  I will push this to
> HEAD unless there are any objections.   If we want them in
> back-branches, we might want to probably segregate the changes based
> on the branch until those apply.

+1.  It would be nice to back-patch the user-visible changes in the
docs.
--
Michael


signature.asc
Description: PGP signature

Re: typos in comments and user docs

[Amit Kapila]

On Thu, Feb 6, 2020 at 10:45 AM Michael Paquier  wrote:
>
> On Thu, Feb 06, 2020 at 08:47:14AM +0530, Amit Kapila wrote:
> > Your changes look fine to me on the first read.  I will push this to
> > HEAD unless there are any objections.   If we want them in
> > back-branches, we might want to probably segregate the changes based
> > on the branch until those apply.
>
> +1.  It would be nice to back-patch the user-visible changes in the
> docs.
>

Fair enough, Justin, is it possible for you to segregate the changes
that can be backpatched?

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Re: typos in comments and user docs

[Justin Pryzby]

On Thu, Feb 06, 2020 at 04:43:18PM +0530, Amit Kapila wrote:
> On Thu, Feb 6, 2020 at 10:45 AM Michael Paquier  wrote:
> >
> > On Thu, Feb 06, 2020 at 08:47:14AM +0530, Amit Kapila wrote:
> > > Your changes look fine to me on the first read.  I will push this to
> > > HEAD unless there are any objections.   If we want them in
> > > back-branches, we might want to probably segregate the changes based
> > > on the branch until those apply.
> >
> > +1.  It would be nice to back-patch the user-visible changes in the
> > docs.
> >
> 
> Fair enough, Justin, is it possible for you to segregate the changes
> that can be backpatched?

Looks like the whole patch can be applied to master and v12 [0].

My original thread from last year was about docs added in v12, so bloom.sgml is
the only user-facing doc which can be backpatched.  README.parallel and
bufmgr.c changes could be backpatched but I agree it's not necessary.

Note, the bloom typo seems to complete a change that was started here:

|commit 31ff51adc855e3ffe8e3c20e479b8d1a4508feb8
|Author: Alexander Korotkov 
|Date:   Mon Oct 22 00:23:26 2018 +0300
|
|Fix some grammar errors in bloom.sgml
|
|Discussion: 
https://postgr.es/m/CAEepm%3D3sijpGr8tXdyz-7EJJZfhQHABPKEQ29gpnb7-XSy%2B%3D5A%40mail.gmail.com
|Reported-by: Thomas Munro
|Backpatch-through: 9.6

Justin

[0] modulo a fix for a typo which I introduced in another patch in this branch,
which shouldn't have been in this patch; fixed in the attached.
>From a1780229e024e2e4b9a0549bcd516bb80b2d5a8d Mon Sep 17 00:00:00 2001
From: Justin Pryzby 
Date: Thu, 9 May 2019 21:13:55 -0500
Subject: [PATCH] spelling and typos

---
 doc/src/sgml/bloom.sgml| 2 +-
 doc/src/sgml/ref/alter_table.sgml  | 2 +-
 doc/src/sgml/sources.sgml  | 4 ++--
 src/backend/access/transam/README.parallel | 2 +-
 src/backend/storage/buffer/bufmgr.c| 2 +-
 src/backend/storage/sync/sync.c| 2 +-
 src/include/access/tableam.h   | 2 +-
 7 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/doc/src/sgml/bloom.sgml b/doc/src/sgml/bloom.sgml
index 6eeadde..c341b65 100644
--- a/doc/src/sgml/bloom.sgml
+++ b/doc/src/sgml/bloom.sgml
@@ -65,7 +65,7 @@
  
   Number of bits generated for each index column. Each parameter's name
   refers to the number of the index column that it controls.  The default
-  is 2 bits and maximum is 4095.  Parameters for
+  is 2 bits and the maximum is 4095.  Parameters for
   index columns not actually used are ignored.
  
 
diff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml
index 5de3676..a22770c 100644
--- a/doc/src/sgml/ref/alter_table.sgml
+++ b/doc/src/sgml/ref/alter_table.sgml
@@ -222,7 +222,7 @@ WITH ( MODULUS numeric_literal, REM
 
  
   SET NOT NULL may only be applied to a column
-  providing none of the records in the table contain a
+  provided none of the records in the table contain a
   NULL value for the column.  Ordinarily this is
   checked during the ALTER TABLE by scanning the
   entire table; however, if a valid CHECK constraint is
diff --git a/doc/src/sgml/sources.sgml b/doc/src/sgml/sources.sgml
index 5831ec4..b5d28e7 100644
--- a/doc/src/sgml/sources.sgml
+++ b/doc/src/sgml/sources.sgml
@@ -511,7 +511,7 @@ Hint:   the addendum
 

 There are functions in the backend that will double-quote their own output
-at need (for example, format_type_be()).  Do not put
+as needed (for example, format_type_be()).  Do not put
 additional quotes around the output of such functions.

 
@@ -880,7 +880,7 @@ BETTER: unrecognized node type: 42
  practices.
 
 
- Features from later revision of the C standard or compiler specific
+ Features from later revisions of the C standard or compiler specific
  features can be used, if a fallback is provided.
 
 
diff --git a/src/backend/access/transam/README.parallel b/src/backend/access/transam/README.parallel
index 85e5840..99c588d 100644
--- a/src/backend/access/transam/README.parallel
+++ b/src/backend/access/transam/README.parallel
@@ -169,7 +169,7 @@ differently because of them.  Right now, we don't even allow that.
 At the end of a parallel operation, which can happen either because it
 completed successfully or because it was interrupted by an error, parallel
 workers associated with that operation exit.  In the error case, transaction
-abort processing in the parallel leader kills of any remaining workers, and
+abort processing in the parallel leader kills off any remaining workers, and
 the parallel leader then waits for them to die.  In the case of a successful
 parallel operation, the parallel leader does not send any signals, but must
 wait for workers to complete and exit of their own volition.  In either
diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c
index aba3960..5880054 100644

Re: typos in comments and user docs

[Amit Kapila]

On Thu, Feb 6, 2020 at 7:26 PM Justin Pryzby  wrote:
>
> On Thu, Feb 06, 2020 at 04:43:18PM +0530, Amit Kapila wrote:
> > On Thu, Feb 6, 2020 at 10:45 AM Michael Paquier  wrote:
> > >
> > > On Thu, Feb 06, 2020 at 08:47:14AM +0530, Amit Kapila wrote:
> > > > Your changes look fine to me on the first read.  I will push this to
> > > > HEAD unless there are any objections.   If we want them in
> > > > back-branches, we might want to probably segregate the changes based
> > > > on the branch until those apply.
> > >
> > > +1.  It would be nice to back-patch the user-visible changes in the
> > > docs.
> > >
> >
> > Fair enough, Justin, is it possible for you to segregate the changes
> > that can be backpatched?
>
> Looks like the whole patch can be applied to master and v12 [0].
>

If we decide to backpatch, then why not try to backpatch as far as
possible (till 9.5)?  If so, then it would be better to separate
changes which can be backpatched till 9.5, if that is tedious, then
maybe we can just back-patch (in 12) bloom.sgml change as a separate
commit and rest commit it in HEAD only.  What do you think?


-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Re: typos in comments and user docs

[Justin Pryzby]

On Fri, Feb 07, 2020 at 08:33:40AM +0530, Amit Kapila wrote:
> On Thu, Feb 6, 2020 at 7:26 PM Justin Pryzby  wrote:
> >
> > On Thu, Feb 06, 2020 at 04:43:18PM +0530, Amit Kapila wrote:
> > > On Thu, Feb 6, 2020 at 10:45 AM Michael Paquier  
> > > wrote:
> > > >
> > > > On Thu, Feb 06, 2020 at 08:47:14AM +0530, Amit Kapila wrote:
> > > > > Your changes look fine to me on the first read.  I will push this to
> > > > > HEAD unless there are any objections.   If we want them in
> > > > > back-branches, we might want to probably segregate the changes based
> > > > > on the branch until those apply.
> > > >
> > > > +1.  It would be nice to back-patch the user-visible changes in the
> > > > docs.
> > > >
> > >
> > > Fair enough, Justin, is it possible for you to segregate the changes
> > > that can be backpatched?
> >
> > Looks like the whole patch can be applied to master and v12 [0].
> 
> If we decide to backpatch, then why not try to backpatch as far as
> possible (till 9.5)?  If so, then it would be better to separate
> changes which can be backpatched till 9.5, if that is tedious, then
> maybe we can just back-patch (in 12) bloom.sgml change as a separate
> commit and rest commit it in HEAD only.  What do you think?

I don't think I was clear.  My original doc review patches were limited to
this:

On Sat, Mar 30, 2019 at 05:43:33PM -0500, Justin Pryzby wrote:
> I reviewed docs like this:
> git log -p remotes/origin/REL_11_STABLE..HEAD -- doc


STABLE..REL_12_STABLE.  So after a few minutes earlier today of cherry-pick, I
concluded that only bloom.sgml is applicable further back than v12.  Probably,
I either noticed that minor issue at the same time as nearby doc changes in
v12(?), or maybe noticed that issue later, independently of doc review, but
then tacked it on to the previous commit, for lack of any better place.

Justin

Re: typos in comments and user docs

[Amit Kapila]

On Fri, Feb 7, 2020 at 8:41 AM Justin Pryzby  wrote:
>
> On Fri, Feb 07, 2020 at 08:33:40AM +0530, Amit Kapila wrote:
> > On Thu, Feb 6, 2020 at 7:26 PM Justin Pryzby  wrote:
> > >
> > > On Thu, Feb 06, 2020 at 04:43:18PM +0530, Amit Kapila wrote:
> > > > On Thu, Feb 6, 2020 at 10:45 AM Michael Paquier  
> > > > wrote:
> > > > >
> > > > > On Thu, Feb 06, 2020 at 08:47:14AM +0530, Amit Kapila wrote:
> > > > > > Your changes look fine to me on the first read.  I will push this to
> > > > > > HEAD unless there are any objections.   If we want them in
> > > > > > back-branches, we might want to probably segregate the changes based
> > > > > > on the branch until those apply.
> > > > >
> > > > > +1.  It would be nice to back-patch the user-visible changes in the
> > > > > docs.
> > > > >
> > > >
> > > > Fair enough, Justin, is it possible for you to segregate the changes
> > > > that can be backpatched?
> > >
> > > Looks like the whole patch can be applied to master and v12 [0].
> >

I tried your patch master and it failed to apply.
(Stripping trailing CRs from patch; use --binary to disable.)
patching file doc/src/sgml/bloom.sgml
(Stripping trailing CRs from patch; use --binary to disable.)
patching file doc/src/sgml/config.sgml
Hunk #1 FAILED at 4318.
1 out of 1 hunk FAILED -- saving rejects to file doc/src/sgml/config.sgml.rej

> > If we decide to backpatch, then why not try to backpatch as far as
> > possible (till 9.5)?  If so, then it would be better to separate
> > changes which can be backpatched till 9.5, if that is tedious, then
> > maybe we can just back-patch (in 12) bloom.sgml change as a separate
> > commit and rest commit it in HEAD only.  What do you think?
>
> I don't think I was clear.  My original doc review patches were limited to
> this:
>
> On Sat, Mar 30, 2019 at 05:43:33PM -0500, Justin Pryzby wrote:
> > I reviewed docs like this:
> > git log -p remotes/origin/REL_11_STABLE..HEAD -- doc
>
>
> STABLE..REL_12_STABLE.  So after a few minutes earlier today of cherry-pick, I
> concluded that only bloom.sgml is applicable further back than v12.  Probably,
> I either noticed that minor issue at the same time as nearby doc changes in
> v12(?), or maybe noticed that issue later, independently of doc review, but
> then tacked it on to the previous commit, for lack of any better place.
>

I am still not 100% clear, it is better if you can prepare a separate
patch which can be backpatched and the rest that we can apply to HEAD.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Re: typos in comments and user docs

[Justin Pryzby]

On Fri, Feb 07, 2020 at 09:26:04AM +0530, Amit Kapila wrote:
> On Fri, Feb 7, 2020 at 8:41 AM Justin Pryzby  wrote:
> >
> > On Fri, Feb 07, 2020 at 08:33:40AM +0530, Amit Kapila wrote:
> > > On Thu, Feb 6, 2020 at 7:26 PM Justin Pryzby  wrote:
> > > >
> > > > On Thu, Feb 06, 2020 at 04:43:18PM +0530, Amit Kapila wrote:
> > > > > On Thu, Feb 6, 2020 at 10:45 AM Michael Paquier  
> > > > > wrote:
> > > > > >
> > > > > > On Thu, Feb 06, 2020 at 08:47:14AM +0530, Amit Kapila wrote:
> > > > > > > Your changes look fine to me on the first read.  I will push this 
> > > > > > > to
> > > > > > > HEAD unless there are any objections.   If we want them in
> > > > > > > back-branches, we might want to probably segregate the changes 
> > > > > > > based
> > > > > > > on the branch until those apply.
> > > > > >
> > > > > > +1.  It would be nice to back-patch the user-visible changes in the
> > > > > > docs.
> > > > > >
> > > > >
> > > > > Fair enough, Justin, is it possible for you to segregate the changes
> > > > > that can be backpatched?
> > > >
> > > > Looks like the whole patch can be applied to master and v12 [0].
> > >
> 
> I tried your patch master and it failed to apply.
> (Stripping trailing CRs from patch; use --binary to disable.)
> patching file doc/src/sgml/bloom.sgml
> (Stripping trailing CRs from patch; use --binary to disable.)
> patching file doc/src/sgml/config.sgml
> Hunk #1 FAILED at 4318.
> 1 out of 1 hunk FAILED -- saving rejects to file doc/src/sgml/config.sgml.rej

I think you applied the first patch, which I corrected here.
https://www.postgresql.org/message-id/20200206135640.GG403%40telsasoft.com

Just rechecked it works for master and v12.

$ git checkout -b test2  origin/master
Branch test2 set up to track remote branch master from origin.
Switched to a new branch 'test2'
$ patch -p1 <0001-spelling-and-typos.patch
patching file doc/src/sgml/bloom.sgml
patching file doc/src/sgml/ref/alter_table.sgml
patching file doc/src/sgml/sources.sgml
patching file src/backend/access/transam/README.parallel
patching file src/backend/storage/buffer/bufmgr.c
patching file src/backend/storage/sync/sync.c
patching file src/include/access/tableam.h

$ patch -p1 <0001-spelling-and-typos.patch
patching file doc/src/sgml/bloom.sgml
patching file doc/src/sgml/ref/alter_table.sgml
Hunk #1 succeeded at 220 (offset -2 lines).
patching file doc/src/sgml/sources.sgml
patching file src/backend/access/transam/README.parallel
patching file src/backend/storage/buffer/bufmgr.c
Hunk #1 succeeded at 4268 (offset -23 lines).
patching file src/backend/storage/sync/sync.c
patching file src/include/access/tableam.h
Hunk #1 succeeded at 1167 (offset -18 lines).

The bloom patch there works for v11.
Attached now another version for v10-.
>From 43c6b9ec80d26a858387ac657043988b8b52e812 Mon Sep 17 00:00:00 2001
From: Justin Pryzby 
Date: Thu, 6 Feb 2020 22:14:20 -0600
Subject: [PATCH] Bloom patch for v10 and v9.6

---
 doc/src/sgml/bloom.sgml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/src/sgml/bloom.sgml b/doc/src/sgml/bloom.sgml
index 87d0ad7..84da235 100644
--- a/doc/src/sgml/bloom.sgml
+++ b/doc/src/sgml/bloom.sgml
@@ -65,7 +65,7 @@
  
   Number of bits generated for each index column. Each parameter's name
   refers to the number of the index column that it controls.  The default
-  is 2 bits and maximum is 4095.  Parameters for
+  is 2 bits and the maximum is 4095.  Parameters for
   index columns not actually used are ignored.
  
 
-- 
2.7.4

Re: typos in comments and user docs

[Amit Kapila]

On Fri, Feb 7, 2020 at 9:47 AM Justin Pryzby  wrote:
>
> On Fri, Feb 07, 2020 at 09:26:04AM +0530, Amit Kapila wrote:
> > On Fri, Feb 7, 2020 at 8:41 AM Justin Pryzby  wrote:
> > >
> > > On Fri, Feb 07, 2020 at 08:33:40AM +0530, Amit Kapila wrote:
> > > > On Thu, Feb 6, 2020 at 7:26 PM Justin Pryzby  
> > > > wrote:
> > > > >
> > > > > On Thu, Feb 06, 2020 at 04:43:18PM +0530, Amit Kapila wrote:
> > > > > > On Thu, Feb 6, 2020 at 10:45 AM Michael Paquier 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Thu, Feb 06, 2020 at 08:47:14AM +0530, Amit Kapila wrote:
> > > > > > > > Your changes look fine to me on the first read.  I will push 
> > > > > > > > this to
> > > > > > > > HEAD unless there are any objections.   If we want them in
> > > > > > > > back-branches, we might want to probably segregate the changes 
> > > > > > > > based
> > > > > > > > on the branch until those apply.
> > > > > > >
> > > > > > > +1.  It would be nice to back-patch the user-visible changes in 
> > > > > > > the
> > > > > > > docs.
> > > > > > >
> > > > > >
> > > > > > Fair enough, Justin, is it possible for you to segregate the changes
> > > > > > that can be backpatched?
> > > > >
> > > > > Looks like the whole patch can be applied to master and v12 [0].
> > > >
> >
> > I tried your patch master and it failed to apply.
> > (Stripping trailing CRs from patch; use --binary to disable.)
> > patching file doc/src/sgml/bloom.sgml
> > (Stripping trailing CRs from patch; use --binary to disable.)
> > patching file doc/src/sgml/config.sgml
> > Hunk #1 FAILED at 4318.
> > 1 out of 1 hunk FAILED -- saving rejects to file 
> > doc/src/sgml/config.sgml.rej
>
> I think you applied the first patch, which I corrected here.
> https://www.postgresql.org/message-id/20200206135640.GG403%40telsasoft.com
>
> Just rechecked it works for master and v12.
>

Okay, thanks.  I have pushed user-facing changes (bloom.sgml and
alter_table.sgml) to back branches till they apply and rest of the
changes in just HEAD.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Re: Typos in the code and README

[David Rowley]

On Sat, 20 Apr 2024 at 16:09, David Rowley  wrote:
> Here are a few more to see if it motivates anyone else to do a more
> thorough search for another batch.

I've pushed these now.

David

Re: Typos in the code and README

[Alexander Lakhin]

Hello,

28.04.2024 11:05, David Rowley wrote:


On Sat, 20 Apr 2024 at 16:09, David Rowley  wrote:

Here are a few more to see if it motivates anyone else to do a more
thorough search for another batch.

I've pushed these now.


Please look also at the list of other typos and inconsistencies I've found
on the master branch:
additional_notnulls -> old_notnulls (cf. b0e96f311)
ATAddCheckConstraint ->? ATAddCheckNNConstraint (cf. b0e96f311)
bt_page_check -> bt_target_page_check (cf. 5ae208720)
calblack_arg -> callback_arg
combinig -> combining
compaining -> complaining
ctllock - remove (cf. 53c2a97a9)
dabatase -> database
eval_const_exprs_mutator -> eval_const_expressions_mutator
ExecEndValuesScan - remove (cf. d060e921e)
get_json_nested_columns -> get_json_table_nested_columns
io_direct -> debug_io_direct
iS ->? IS (a neatnik-ism)
joing ->? join (cf. 20f90a0e4)
_jumbleRangeTblEntry - remove (cf. 367c989cd)
Mallroy -> Mallory
onstead -> instead
procedual -> procedural
psql_safe -> safe_psql
read_quoted_pattern -> read_quoted_string
repertiore -> repertoire
rightfirstdataoffset ->? rightfirstoffset (cf. 5ae208720)
Sincle ->? Since (perhaps the whole sentence could be rephrased)
sslnegotition=direct/requiredirectwould -> sslnegotiation=direct/requiredirect 
would
sslnegotitation -> sslnegotiation
walreciever -> walreceiver
xid_wrapround -> xid_wraparound

(some of them are located in doc/, so it's not a code-only change)
I've attached the patch for your convenience, though maybe some
of the suggestions are to be discarded.

Best regards,
Alexanderdiff --git a/contrib/amcheck/verify_nbtree.c b/contrib/amcheck/verify_nbtree.c
index 20da4a46ba..70f65b645a 100644
--- a/contrib/amcheck/verify_nbtree.c
+++ b/contrib/amcheck/verify_nbtree.c
@@ -1086,7 +1086,7 @@ bt_entry_unique_check(BtreeCheckState *state, IndexTuple itup,
 
 	/*
 	 * Current tuple has no posting list. If TID is visible save info about it
-	 * for the next comparisons in the loop in bt_page_check(). Report
+	 * for the next comparisons in the loop in bt_target_page_check(). Report
 	 * duplicate if lVis_tid is already valid.
 	 */
 	else
@@ -1953,7 +1953,7 @@ bt_target_page_check(BtreeCheckState *state)
  * Note that !readonly callers must reverify that target page has not
  * been concurrently deleted.
  *
- * Save rightfirstdataoffset for detailed error message.
+ * Save rightfirstoffset for detailed error message.
  */
 static BTScanInsert
 bt_right_page_check_scankey(BtreeCheckState *state, OffsetNumber *rightfirstoffset)
diff --git a/doc/src/sgml/regress.sgml b/doc/src/sgml/regress.sgml
index d7e78204ad..f4b00399e4 100644
--- a/doc/src/sgml/regress.sgml
+++ b/doc/src/sgml/regress.sgml
@@ -331,7 +331,7 @@ make check-world PG_TEST_EXTRA='kerberos ldap ssl load_balance libpq_encryption'
  xid_wraparound
  
   
-   Runs the test suite under src/test/module/xid_wrapround.
+   Runs the test suite under src/test/module/xid_wraparound.
Not enabled by default because it is resource intensive.
   
  
diff --git a/doc/src/sgml/targets-meson.txt b/doc/src/sgml/targets-meson.txt
index 1c42dd3028..bd470c87a7 100644
--- a/doc/src/sgml/targets-meson.txt
+++ b/doc/src/sgml/targets-meson.txt
@@ -11,7 +11,7 @@ Code Targets:
   backend   Build backend and related modules
   bin   Build frontend binaries
   contrib   Build contrib modules
-  plBuild procedual languages
+  plBuild procedural languages
 
 Developer Targets:
   reformat-dat-filesRewrite catalog data files into standard format
diff --git a/src/backend/access/brin/brin.c b/src/backend/access/brin/brin.c
index bf28400dd8..d0f3848c95 100644
--- a/src/backend/access/brin/brin.c
+++ b/src/backend/access/brin/brin.c
@@ -2598,7 +2598,7 @@ _brin_parallel_heapscan(BrinBuildState *state)
  *
  * After waiting for all workers to finish, merge the per-worker results into
  * the complete index. The results from each worker are sorted by block number
- * (start of the page range). While combinig the per-worker results we merge
+ * (start of the page range). While combining the per-worker results we merge
  * summaries for the same page range, and also fill-in empty summaries for
  * ranges without any tuples.
  *
diff --git a/src/backend/access/transam/slru.c b/src/backend/access/transam/slru.c
index f99ec38a4a..77b05cc0a7 100644
--- a/src/backend/access/transam/slru.c
+++ b/src/backend/access/transam/slru.c
@@ -228,7 +228,6 @@ SimpleLruAutotuneBuffers(int divisor, int max)
  * name: name of SLRU.  (This is user-visible, pick with care!)
  * nslots: number of page slots to use.
  * nlsns: number of LSN groups per page (set to zero if not relevant).
- * ctllock: LWLock to use to control access to the shared control structure.
  * subdir: PGDATA-relative subdirectory that will contain the files.
  * buffer_tranche_id: tranche ID to use for the SLRU's p

Re: Typos in the code and README

[David Rowley]

On Fri, 3 May 2024 at 00:00, Alexander Lakhin  wrote:
> (some of them are located in doc/, so it's not a code-only change)
> I've attached the patch for your convenience, though maybe some
> of the suggestions are to be discarded.

Thanks. I was hoping you'd do that.

I pushed the patch after only adjusting the path in the docs which had
"module" rather than "modules".

David

Re: Typos in the code and README

[Alexander Lakhin]

Hello hackers,

03.05.2024 17:36, David Rowley wrote:

I pushed the patch after only adjusting the path in the docs which had
"module" rather than "modules".


Please look at another bunch of inconsistencies/orphaned entities I found
in the tree, with the possible substitutions:
errmsg_buf -> errormsg_buf
(coined by 6b18b3fe2)

NoMovementScanDirectionScans -> NoMovementScanDirection
(introduced with e9aaf0632, discussed in [1], but still seems inaccurate)

XLogReadRecordInternal -> XLogReadRecord
(from 3f1ce9734, align with a comment above: "Start and end point of last
record returned by XLogReadRecord().")

BYPASS_ALLOWCONN -> BGWORKER_BYPASS_ROLELOGINCHECK (see 492217301)

xs_ctup.t_self -> xs_heaptid (see c2fe139c2 and 304532421)

pgStatShmLookupCache -> pgStatLocal.shmem (coined by 5891c7a8e)

smgr_fsm_nblocks and smgr_vm_nblocks -> smgr_cached_nblocks
(see the same comment updated by c5315f4f4)

XID becomes older than GlobalXmin -> XID becomes visible to everyone
(in accordance with dc7420c2c9 src/backend/access/gist/gistutil.c)

gen-rtab - remove (non-existing since db7d1a7b0)

BARRIER_SHOULD_CHECK - remove (unused since a3ed4d1ef)

EXE_EXT - remove (unused since f06b1c598)

endterm - remove
(see 60c90c16c -- Use xreflabel attributes instead of endterm ...)

xl_commit_ts_set, SizeOfCommitTsSet - remove (unused since 08aa89b32)

The corresponding patch is attached for your convenience.

[1] 
https://www.postgresql.org/message-id/20230131140224.7j6gbcsfwmad2a4b%40liskov

Best regards,
Alexanderdiff --git a/contrib/pgcrypto/Makefile b/contrib/pgcrypto/Makefile
index 5efa10c334..85f1c94681 100644
--- a/contrib/pgcrypto/Makefile
+++ b/contrib/pgcrypto/Makefile
@@ -45,8 +45,6 @@ REGRESS = init md5 sha1 hmac-md5 hmac-sha1 blowfish rijndael \
 	pgp-armor pgp-decrypt pgp-encrypt pgp-encrypt-md5 $(CF_PGP_TESTS) \
 	pgp-pubkey-decrypt pgp-pubkey-encrypt pgp-info
 
-EXTRA_CLEAN = gen-rtab
-
 ifdef USE_PGXS
 PG_CONFIG = pg_config
 PGXS := $(shell $(PG_CONFIG) --pgxs)
diff --git a/doc/src/sgml/README.links b/doc/src/sgml/README.links
index 65df9c111f..900e0308b6 100644
--- a/doc/src/sgml/README.links
+++ b/doc/src/sgml/README.links
@@ -15,10 +15,6 @@ Intra-document Linking
 linkend=
 	controls the target of the link/xref, required
 
-endterm=
-	for , allows the text of the link/xref to be taken from a
-	different link target title
-
 
 	use to supply text for the link, only uses linkend, requires 
 	http://www.oasis-open.org/docbook/documentation/reference/html/link.html
diff --git a/src/backend/access/gist/gistvacuum.c b/src/backend/access/gist/gistvacuum.c
index 24fb94f473..59372783d0 100644
--- a/src/backend/access/gist/gistvacuum.c
+++ b/src/backend/access/gist/gistvacuum.c
@@ -643,7 +643,7 @@ gistdeletepage(IndexVacuumInfo *info, IndexBulkDeleteResult *stats,
 	 * The page cannot be immediately recycled, because in-progress scans that
 	 * saw the downlink might still visit it.  Mark the page with the current
 	 * next-XID counter, so that we know when it can be recycled.  Once that
-	 * XID becomes older than GlobalXmin, we know that all scans that are
+	 * XID becomes visible to everyone, we know that all scans that are
 	 * currently in progress must have ended.  (That's much more conservative
 	 * than needed, but let's keep it safe and simple.)
 	 */
diff --git a/src/backend/access/transam/xlogreader.c b/src/backend/access/transam/xlogreader.c
index 37d2a57961..45bc17e7f4 100644
--- a/src/backend/access/transam/xlogreader.c
+++ b/src/backend/access/transam/xlogreader.c
@@ -946,7 +946,7 @@ err:
 	XLogReaderInvalReadState(state);
 
 	/*
-	 * If an error was written to errmsg_buf, it'll be returned to the caller
+	 * If an error was written to errormsg_buf, it'll be returned to the caller
 	 * of XLogReadRecord() after all successfully decoded records from the
 	 * read queue.
 	 */
diff --git a/src/backend/executor/execCurrent.c b/src/backend/executor/execCurrent.c
index 70c62ac110..5285b84d30 100644
--- a/src/backend/executor/execCurrent.c
+++ b/src/backend/executor/execCurrent.c
@@ -200,7 +200,7 @@ execCurrentOf(CurrentOfExpr *cexpr,
 			/*
 			 * For IndexOnlyScan, the tuple stored in ss_ScanTupleSlot may be
 			 * a virtual tuple that does not have the ctid column, so we have
-			 * to get the TID from xs_ctup.t_self.
+			 * to get the TID from xs_heaptid.
 			 */
 			IndexScanDesc scan = ((IndexOnlyScanState *) scanstate)->ioss_ScanDesc;
 
diff --git a/src/backend/storage/ipc/procsignal.c b/src/backend/storage/ipc/procsignal.c
index 4ed9cedcdd..d9a84b66e0 100644
--- a/src/backend/storage/ipc/procsignal.c
+++ b/src/backend/storage/ipc/procsignal.c
@@ -88,10 +88,6 @@ typedef struct
  */
 #define NumProcSignalSlots	(MaxBackends + NUM_AUXILIARY_PROCS)
 
-/* Check whether the relevant type bit is set in the flags. */
-#define BARRIER_SHOULD_CHECK(flags, type) \
-	(((flags) & (((uint32) 1) << (uint32) (type))) != 0)
-
 /* Clear the relevant type bit from the flags. */
 #define BARRIER_CLEAR_BIT(flags, type

Re: Typos in the code and README

[Daniel Gustafsson]

> On 4 Jul 2024, at 19:00, Alexander Lakhin  wrote:

> Please look at another bunch of inconsistencies/orphaned entities I found
> in the tree, with the possible substitutions:

Thanks for these, and sorry for the delay in processing them (summer happened
etc).  I've started to go through them and have applied some low-hanging fruit
already, will go over all them.

--
Daniel Gustafsson

Re: Typos in the code and README

[David Rowley]

(I know Daniel mentioned he'd get to these, but the ScanDirection one
was my fault and I needed to clear that off my mind. I did a few
others while on this topic.)

On Fri, 5 Jul 2024 at 05:00, Alexander Lakhin  wrote:
> Please look at another bunch of inconsistencies/orphaned entities I found
> in the tree, with the possible substitutions:
> errmsg_buf -> errormsg_buf
> (coined by 6b18b3fe2)

Fixed.

> NoMovementScanDirectionScans -> NoMovementScanDirection
> (introduced with e9aaf0632, discussed in [1], but still seems inaccurate)

Oops. Fixed.

> XLogReadRecordInternal -> XLogReadRecord
> (from 3f1ce9734, align with a comment above: "Start and end point of last
> record returned by XLogReadRecord().")

Fixed.

> BYPASS_ALLOWCONN -> BGWORKER_BYPASS_ROLELOGINCHECK (see 492217301)

Fixed

> xs_ctup.t_self -> xs_heaptid (see c2fe139c2 and 304532421)

Fixed.

> pgStatShmLookupCache -> pgStatLocal.shmem (coined by 5891c7a8e)

Fixed.

> smgr_fsm_nblocks and smgr_vm_nblocks -> smgr_cached_nblocks
> (see the same comment updated by c5315f4f4)

Heikki fixed in 19de089cd.

> XID becomes older than GlobalXmin -> XID becomes visible to everyone
> (in accordance with dc7420c2c9 src/backend/access/gist/gistutil.c)

I'd need to spend more time to understand this.

> gen-rtab - remove (non-existing since db7d1a7b0)

Daniel fixed in cc59f9d0f.

> BARRIER_SHOULD_CHECK - remove (unused since a3ed4d1ef)

I wasn't sure if nothing else external could be using this. The macro
doesn't use any fields that are now gone, so I'm not confident enough
to remove it. Can Robert confirm?

> EXE_EXT - remove (unused since f06b1c598)

Daniel fixed in 88e3da565.

> endterm - remove
> (see 60c90c16c -- Use xreflabel attributes instead of endterm ...)

I read that commit message and I agree it's now unused. I just didn't
get any vibes from the commit message that it shouldn't ever be used
again.  Can Tom confirm?

> xl_commit_ts_set, SizeOfCommitTsSet - remove (unused since 08aa89b32)

I would say it should be removed.  I just didn't because the commit I
had pending fitted into the "typos" category and this didn't quite
fit.

I've attached a patch with the remainder.

David


remaining_typos.patch
Description: Binary data

Re: Typos in the code and README

[Alexander Lakhin]

Hello,

12.08.2024 14:59, David Rowley wrote:

(I know Daniel mentioned he'd get to these, but the ScanDirection one
was my fault and I needed to clear that off my mind. I did a few
others while on this topic.)


Thank you, David, for working on that!

I've gathered another bunch of defects with the possible substitutions.
Please take a look:
adapated -> adapted

becasue -> because

cancelled -> canceled (introduced by 90f517821, but see 8c9da1441)

cange -> change

comand -> command

CommitTSSLRU -> CommitTsSLRU (introduced by 53c2a97a9; maybe the fix
 should be back-patched...)

connectOptions2 -> pqConnectOptions2 (see 774bcffe4)

Injections points -> Injection points

jsetate -> jsestate

LockShmemSize -> remove the sentence? (added by ec0baf949, outdated with
 a794fb068)

MaybeStartSlotSyncWorker -> LaunchMissingBackgroundProcesses (the logic to
 start B_SLOTSYNC_WORKER moved from the former to the latter function with
 3354f8528)

multixact_member_buffer -> multixact_member_buffers

per_data_data -> per_buffer_data (see code below the comment; introduced by
 b5a9b18cd)

per_buffer_private -> remove the function declaration? (the duplicate
 declaration was added by a858be17c)

performancewise -> performance-wise? (coined by a7f107df2)

pgstat_add_kind -> pgstat_register_kind (see 7949d9594)

pg_signal_autovacuum -> pg_signal_autovacuum_worker (see d2b74882c)

recoveery -> recovery

RegisteredWorker -> RegisteredBgWorker

RUNNING_XACT -> RUNNING_XACTS

sanpshot -> snapshot

TypeEntry -> TypeCacheEntry (align with AttoptCacheEntry, from the same
 commit 40064a8ee)

The corresponding patch is attached for your convenience.

Best regards,
Alexanderdiff --git a/contrib/test_decoding/specs/skip_snapshot_restore.spec b/contrib/test_decoding/specs/skip_snapshot_restore.spec
index 3f1fb6f02c7..7b35dbcc9f3 100644
--- a/contrib/test_decoding/specs/skip_snapshot_restore.spec
+++ b/contrib/test_decoding/specs/skip_snapshot_restore.spec
@@ -39,7 +39,7 @@ step "s2_get_changes_slot0" { SELECT data FROM pg_logical_slot_get_changes('slot
 # serializes consistent snapshots to the disk at LSNs where are before
 # s0-transaction's commit. After s0-transaction commits, "s1_init" resumes but
 # must not restore any serialized snapshots and will reach the consistent state
-# when decoding a RUNNING_XACT record generated after s0-transaction's commit.
+# when decoding a RUNNING_XACTS record generated after s0-transaction's commit.
 # We check if the get_changes on 'slot1' will not return any s0-transaction's
 # changes as its confirmed_flush_lsn will be after the s0-transaction's commit
 # record.
diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml
index 9bc23a9a938..af7864a1b5b 100644
--- a/doc/src/sgml/xfunc.sgml
+++ b/doc/src/sgml/xfunc.sgml
@@ -3891,8 +3891,8 @@ static const PgStat_KindInfo custom_stats = {
  it with pgstat_register_kind and a unique ID used to
  store the entries related to this type of statistics:
 
-extern PgStat_Kind pgstat_add_kind(PgStat_Kind kind,
-   const PgStat_KindInfo *kind_info);
+extern PgStat_Kind pgstat_register_kind(PgStat_Kind kind,
+const PgStat_KindInfo *kind_info);
 
  While developing a new extension, use
  PGSTAT_KIND_EXPERIMENTAL for
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index a03d56541d0..8c37d7eba76 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2017,7 +2017,7 @@ check_multixact_offset_buffers(int *newval, void **extra, GucSource source)
 }
 
 /*
- * GUC check_hook for multixact_member_buffer
+ * GUC check_hook for multixact_member_buffers
  */
 bool
 check_multixact_member_buffers(int *newval, void **extra, GucSource source)
diff --git a/src/backend/commands/matview.c b/src/backend/commands/matview.c
index 91f0fd6ea3e..b2457f121a7 100644
--- a/src/backend/commands/matview.c
+++ b/src/backend/commands/matview.c
@@ -382,7 +382,7 @@ RefreshMatViewByOid(Oid matviewOid, bool is_create, bool skipData,
 	 * command tag is left false in cmdtaglist.h. Otherwise, the change of
 	 * completion tag output might break applications using it.
 	 *
-	 * When called from CREATE MATERIALIZED VIEW comand, the rowcount is
+	 * When called from CREATE MATERIALIZED VIEW command, the rowcount is
 	 * displayed with the command tag CMDTAG_SELECT.
 	 */
 	if (qc)
diff --git a/src/backend/commands/waitlsn.c b/src/backend/commands/waitlsn.c
index d9cf9e7d75e..d7065726749 100644
--- a/src/backend/commands/waitlsn.c
+++ b/src/backend/commands/waitlsn.c
@@ -369,7 +369,7 @@ pg_wal_replay_wait(PG_FUNCTION_ARGS)
 	 */
 	InvalidateCatalogSnapshot();
 
-	/* Give up if there is still an active or registered sanpshot. */
+	/* Give up if there is still an active or registered snapshot. */
 	if (GetOldestSnapshot())
 		ereport(ERROR,
 (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
diff --git a/src/backe

Re: Typos in the code and README

[Andrew Dunstan]

On 2024-04-11 Th 09:05, Daniel Gustafsson wrote:

Now that the tree has settled down a bit post-freeze I ran some tooling to
check spelling.  I was primarily interested in docs and README* which were
mostly free from simply typos, while the code had some in various comments and
one in code.  The attached fixes all that I came across (not cross-referenced
against ongoing reverts or any other fixup threads but will be before pushing
of course).




I have these covered:


src/test/modules/test_json_parser/README  | 2 +-
.../test_json_parser/test_json_parser_incremental.c   | 4 ++--
src/test/modules/test_json_parser/test_json_parser_perf.c | 2 +-


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Re: Typos in the code and README

[David Rowley]

On Fri, 12 Apr 2024, 1:05 am Daniel Gustafsson,  wrote:

> Now that the tree has settled down a bit post-freeze I ran some tooling to
> check spelling.  I was primarily interested in docs and README* which were
> mostly free from simply typos, while the code had some in various comments
> and
> one in code.  The attached fixes all that I came across (not
> cross-referenced
> against ongoing reverts or any other fixup threads but will be before
> pushing
> of course).
>

I see you've corrected "iif" to "if". It should be "iff".

David

>

Re: Typos in the code and README

[Daniel Gustafsson]

> On 11 Apr 2024, at 15:29, David Rowley  wrote:
> 
> On Fri, 12 Apr 2024, 1:05 am Daniel Gustafsson,  > wrote:
>> Now that the tree has settled down a bit post-freeze I ran some tooling to
>> check spelling.  I was primarily interested in docs and README* which were
>> mostly free from simply typos, while the code had some in various comments 
>> and
>> one in code.  The attached fixes all that I came across (not cross-referenced
>> against ongoing reverts or any other fixup threads but will be before pushing
>> of course).
> 
> 
> I see you've corrected "iif" to "if". It should be "iff".

Gotcha, will fix.  I opted for "if" due to recent threads where the use of
"iff" was discouraged due to not being commonly known, but that was in doc/ and
not code comments.

--
Daniel Gustafsson

Re: Typos in the code and README

[Bruce Momjian]

On Thu, Apr 11, 2024 at 03:37:00PM +0200, Daniel Gustafsson wrote:
> On 11 Apr 2024, at 15:29, David Rowley  wrote:
> 
> On Fri, 12 Apr 2024, 1:05 am Daniel Gustafsson,  wrote:
> 
> Now that the tree has settled down a bit post-freeze I ran some 
> tooling
> to
> check spelling.  I was primarily interested in docs and README* which
> were
> mostly free from simply typos, while the code had some in various
> comments and
> one in code.  The attached fixes all that I came across (not
> cross-referenced
> against ongoing reverts or any other fixup threads but will be before
> pushing
> of course).
> 
> 
> I see you've corrected "iif" to "if". It should be "iff".
> 
> 
> Gotcha, will fix.  I opted for "if" due to recent threads where the use of
> "iff" was discouraged due to not being commonly known, but that was in doc/ 
> and
> not code comments.

I actually agree "iff" is just not clear enough.  "Iff" stands for "if
and only if" and maybe should be spelled out that way.

-- 
  Bruce Momjian  https://momjian.us
  EDB  https://enterprisedb.com

  Only you can decide what is important to you.

Re: Typos in the code and README

[Bruce Momjian]

On Fri, Apr 12, 2024 at 04:55:16PM -0400, Bruce Momjian wrote:
> On Thu, Apr 11, 2024 at 03:37:00PM +0200, Daniel Gustafsson wrote:
> > On 11 Apr 2024, at 15:29, David Rowley  wrote:
> > 
> > On Fri, 12 Apr 2024, 1:05 am Daniel Gustafsson,  wrote:
> > 
> > Now that the tree has settled down a bit post-freeze I ran some 
> > tooling
> > to
> > check spelling.  I was primarily interested in docs and README* 
> > which
> > were
> > mostly free from simply typos, while the code had some in various
> > comments and
> > one in code.  The attached fixes all that I came across (not
> > cross-referenced
> > against ongoing reverts or any other fixup threads but will be 
> > before
> > pushing
> > of course).
> > 
> > 
> > I see you've corrected "iif" to "if". It should be "iff".
> > 
> > 
> > Gotcha, will fix.  I opted for "if" due to recent threads where the use of
> > "iff" was discouraged due to not being commonly known, but that was in doc/ 
> > and
> > not code comments.
> 
> I actually agree "iff" is just not clear enough.  "Iff" stands for "if
> and only if" and maybe should be spelled out that way.

Just to clarify, I think "if and only if" means "if A then B" and B can
only happen if A happens, meaning there are not other cases where B can
happen.  This latter part is what disinguishes "iff" from "if".

-- 
  Bruce Momjian  https://momjian.us
  EDB  https://enterprisedb.com

  Only you can decide what is important to you.

Re: Typos in the code and README

[Heikki Linnakangas]

On 11/04/2024 16:05, Daniel Gustafsson wrote:

Now that the tree has settled down a bit post-freeze I ran some tooling to
check spelling.  I was primarily interested in docs and README* which were
mostly free from simply typos, while the code had some in various comments and
one in code.  The attached fixes all that I came across (not cross-referenced
against ongoing reverts or any other fixup threads but will be before pushing
of course).


Here's a few more. I've accumulate these over the past couple of months, 
keeping them stashed in a branch, adding to it whenever I've spotted a 
minor typo while reading the code.


--
Heikki Linnakangas
Neon (https://neon.tech)
From 5f531b719c176b2f316b6341fa062af508ed2e10 Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas 
Date: Sun, 7 Apr 2024 22:34:23 +0300
Subject: [PATCH 1/2] fix typos

---
 doc/src/sgml/maintenance.sgml   | 2 +-
 doc/src/sgml/meson.build| 2 +-
 src/backend/access/rmgrdesc/xactdesc.c  | 2 +-
 src/backend/catalog/system_functions.sql| 2 +-
 src/backend/commands/amcmds.c   | 2 +-
 src/backend/commands/tablecmds.c| 4 ++--
 src/backend/postmaster/walsummarizer.c  | 2 +-
 src/backend/replication/logical/slotsync.c  | 2 +-
 src/backend/statistics/dependencies.c   | 4 ++--
 src/backend/utils/adt/multirangetypes.c | 2 +-
 src/backend/utils/mmgr/aset.c   | 4 ++--
 src/backend/utils/mmgr/generation.c | 4 ++--
 src/bin/pg_basebackup/bbstreamer_tar.c  | 2 +-
 src/bin/pg_combinebackup/pg_combinebackup.c | 2 +-
 src/interfaces/libpq/fe-secure-openssl.c| 2 +-
 src/test/modules/test_resowner/test_resowner_many.c | 2 +-
 src/test/regress/expected/aggregates.out| 2 +-
 src/test/regress/sql/aggregates.sql | 2 +-
 18 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 2bfa05b8bc..0be90bdc7e 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -802,7 +802,7 @@ HINT:  Execute a database-wide VACUUM in that database.
 
  Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
  system will begin to emit warning messages when the database's oldest MXIDs reach forty
- million transactions from the wraparound point.  And, just as an the XID case, if these
+ million transactions from the wraparound point.  And, just as in the XID case, if these
  warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
  than three million left until wraparound.
 
diff --git a/doc/src/sgml/meson.build b/doc/src/sgml/meson.build
index 3a4b47d387..e418de83a7 100644
--- a/doc/src/sgml/meson.build
+++ b/doc/src/sgml/meson.build
@@ -207,7 +207,7 @@ if docs_dep.found()
   alias_target('man', man)
   alias_target('install-man', install_doc_man)
 
-  # built and installed as part of the the docs target
+  # built and installed as part of the docs target
   installdocs += install_doc_man
   docs += man
 endif
diff --git a/src/backend/access/rmgrdesc/xactdesc.c b/src/backend/access/rmgrdesc/xactdesc.c
index 41b842d80e..dccca201e0 100644
--- a/src/backend/access/rmgrdesc/xactdesc.c
+++ b/src/backend/access/rmgrdesc/xactdesc.c
@@ -25,7 +25,7 @@
  * Parse the WAL format of an xact commit and abort records into an easier to
  * understand format.
  *
- * This routines are in xactdesc.c because they're accessed in backend (when
+ * These routines are in xactdesc.c because they're accessed in backend (when
  * replaying WAL) and frontend (pg_waldump) code. This file is the only xact
  * specific one shared between both. They're complicated enough that
  * duplication would be bothersome.
diff --git a/src/backend/catalog/system_functions.sql b/src/backend/catalog/system_functions.sql
index fe2bb50f46..ae099e328c 100644
--- a/src/backend/catalog/system_functions.sql
+++ b/src/backend/catalog/system_functions.sql
@@ -5,7 +5,7 @@
  *
  * src/backend/catalog/system_functions.sql
  *
- * This file redefines certain built-in functions that it's impractical
+ * This file redefines certain built-in functions that are impractical
  * to fully define in pg_proc.dat.  In most cases that's because they use
  * SQL-standard function bodies and/or default expressions.  The node
  * tree representations of those are too unreadable, platform-dependent,
diff --git a/src/backend/commands/amcmds.c b/src/backend/commands/amcmds.c
index 10e386288a..aaa0f9a1dc 100644
--- a/src/backend/commands/amcmds.c
+++ b/src/backend/commands/amcmds.c
@@ -167,7 +167,7 @@ get_index_am_oid(const char *amname, bool missing_ok)
 
 /*
  * get_table_am_oid - given an access method name, look up its OID
- *		and verify it corresponds to an table AM.
+ *		and verify it corresponds to a table AM.
  */
 Oid
 g

Re: Typos in the code and README

[Daniel Gustafsson]

> On 12 Apr 2024, at 23:15, Heikki Linnakangas  wrote:
> 
> On 11/04/2024 16:05, Daniel Gustafsson wrote:
>> Now that the tree has settled down a bit post-freeze I ran some tooling to
>> check spelling.  I was primarily interested in docs and README* which were
>> mostly free from simply typos, while the code had some in various comments 
>> and
>> one in code.  The attached fixes all that I came across (not cross-referenced
>> against ongoing reverts or any other fixup threads but will be before pushing
>> of course).
> 
> Here's a few more. I've accumulate these over the past couple of months, 
> keeping them stashed in a branch, adding to it whenever I've spotted a minor 
> typo while reading the code.

Nice, let's lot all these together.

--
Daniel Gustafsson

Re: Typos in the code and README

[David Rowley]

On Sat, 13 Apr 2024 at 09:17, Daniel Gustafsson  wrote:
>
> > On 12 Apr 2024, at 23:15, Heikki Linnakangas  wrote:
> > Here's a few more. I've accumulate these over the past couple of months, 
> > keeping them stashed in a branch, adding to it whenever I've spotted a 
> > minor typo while reading the code.
>
> Nice, let's lot all these together.

Here are a few additional ones to add to that.

Found with a manual trawl through git grep -E
'\b([a-zA-Z]{2,}[^long|^that])\s+\1\b' -- ':!*.po' ':!*.dat'

David
diff --git a/contrib/amcheck/verify_nbtree.c b/contrib/amcheck/verify_nbtree.c
index f71f1854e0..20da4a46ba 100644
--- a/contrib/amcheck/verify_nbtree.c
+++ b/contrib/amcheck/verify_nbtree.c
@@ -3036,7 +3036,7 @@ bt_normalize_tuple(BtreeCheckState *state, IndexTuple 
itup)
 * In the heap, tuples may contain short varlena datums with both 1B
 * header and 4B headers.  But the corresponding index tuple should 
always
 * have such varlena's with 1B headers.  So, if there is a short varlena
-* with 4B header, we need to convert it for for fingerprinting.
+* with 4B header, we need to convert it for fingerprinting.
 *
 * Note that we rely on deterministic index_form_tuple() TOAST 
compression
 * of normalized input.
diff --git a/src/backend/access/nbtree/nbtutils.c 
b/src/backend/access/nbtree/nbtutils.c
index 2eff34c4aa..725811034f 100644
--- a/src/backend/access/nbtree/nbtutils.c
+++ b/src/backend/access/nbtree/nbtutils.c
@@ -1756,7 +1756,7 @@ _bt_start_prim_scan(IndexScanDesc scan, ScanDirection dir)
  *
  * (The rules are the same for backwards scans, except that the operators are
  * flipped: just replace the precondition's >= operator with a <=, and the
- * postcondition's <= operator with with a >=.  In other words, just swap the
+ * postcondition's <= operator with a >=.  In other words, just swap the
  * precondition with the postcondition.)
  *
  * We also deal with "advancing" non-required arrays here.  Callers whose
diff --git a/src/backend/partitioning/partbounds.c 
b/src/backend/partitioning/partbounds.c
index c0c49b0a0b..af3b1a90d2 100644
--- a/src/backend/partitioning/partbounds.c
+++ b/src/backend/partitioning/partbounds.c
@@ -5145,7 +5145,7 @@ get_partition_bound_spec(Oid partOid, RangeVar *name)
  * the first of new partitions) then lower bound of "spec" should be equal (or
  * greater than or equal in case defaultPart=true) to lower bound of split
  * partition. If last=true (this means that "spec" is the last of new
- * partitions) then upper bound of of "spec" should be equal (or less than or
+ * partitions) then upper bound of "spec" should be equal (or less than or
  * equal in case defaultPart=true) to upper bound of split partition.
  *
  * parent: partitioned table
@@ -5244,7 +5244,7 @@ check_partition_bounds_for_split_range(Relation parent,

  false, split_upper);
 
/*
-* Upper bound of of "spec" should be equal (or less 
than or equal
+* Upper bound of "spec" should be equal (or less than 
or equal
 * in case defaultPart=true) to upper bound of split 
partition.
 */
if ((!defaultPart && cmpval) || (defaultPart && cmpval 
> 0))
diff --git a/src/backend/storage/aio/read_stream.c 
b/src/backend/storage/aio/read_stream.c
index f54dacdd91..634cf4f0d1 100644
--- a/src/backend/storage/aio/read_stream.c
+++ b/src/backend/storage/aio/read_stream.c
@@ -541,9 +541,9 @@ read_stream_begin_relation(int flags,
stream->distance = 1;
 
/*
-* Since we always always access the same relation, we can initialize
-* parts of the ReadBuffersOperation objects and leave them that way, to
-* avoid wasting CPU cycles writing to them for each read.
+* Since we always access the same relation, we can initialize parts of
+* the ReadBuffersOperation objects and leave them that way, to avoid
+* wasting CPU cycles writing to them for each read.
 */
for (int i = 0; i < max_ios; ++i)
{
diff --git a/src/backend/utils/mmgr/bump.c b/src/backend/utils/mmgr/bump.c
index 449bd29344..26d2907fb7 100644
--- a/src/backend/utils/mmgr/bump.c
+++ b/src/backend/utils/mmgr/bump.c
@@ -501,8 +501,8 @@ BumpAlloc(MemoryContext context, Size size, int flags)
 #endif
 
/*
-* If requested size exceeds maximum for chunks we hand the the request
-* off to BumpAllocLarge().
+* If requested size exceeds maximum for chunks we hand the request off 
to
+* BumpAllocLarge().
 */
if (chunk_size > set->allocChunkLimit)
return BumpAllocLarge(context, size, flags);
diff --git a/src/bin/pg_combinebackup/reconstruct.c 
b/src/bin/pg_combinebackup/reconstruct.c
index 15f62c18df..d481a5c56

Re: Typos in the code and README

[Daniel Gustafsson]

> On 14 Apr 2024, at 13:19, David Rowley  wrote:
> 
> On Sat, 13 Apr 2024 at 09:17, Daniel Gustafsson  wrote:
>> 
>>> On 12 Apr 2024, at 23:15, Heikki Linnakangas  wrote:
>>> Here's a few more. I've accumulate these over the past couple of months, 
>>> keeping them stashed in a branch, adding to it whenever I've spotted a 
>>> minor typo while reading the code.
>> 
>> Nice, let's lot all these together.
> 
> Here are a few additional ones to add to that.

Thanks.  Collecting all the ones submitted here, as well as a few submitted
off-list by Alexander, the patch is now a 3-part patchset of cleanups:

0001 contains the typos and duplicate words fixups, 0002 fixes a parameter with
the wrong name in the prototype and 0003 removes a leftover prototype which was
accidentally left in a refactoring.

--
Daniel Gustafsson



v2-0003-Remove-unused-function-prototype.patch
Description: Binary data


v2-0002-Fix-incorrect-parameter-name-in-prototype.patch
Description: Binary data


v2-0001-Fix-typos-and-duplicate-words-in-comments.patch
Description: Binary data

Re: Typos in the code and README

[Richard Guo]

On Mon, Apr 15, 2024 at 8:26 PM Daniel Gustafsson  wrote:

> Thanks.  Collecting all the ones submitted here, as well as a few submitted
> off-list by Alexander, the patch is now a 3-part patchset of cleanups:
>
> 0001 contains the typos and duplicate words fixups, 0002 fixes a parameter
> with
> the wrong name in the prototype and 0003 removes a leftover prototype
> which was
> accidentally left in a refactoring.


BTW, it seems that 0001 needs a rebase over 9dfcac8e15.

Thanks
Richard

Re: Typos in the code and README

[Nazir Bilal Yavuz]

Hi,

Thanks for working on this!

On Mon, 15 Apr 2024 at 15:26, Daniel Gustafsson  wrote:
>
> > On 14 Apr 2024, at 13:19, David Rowley  wrote:
> >
> > On Sat, 13 Apr 2024 at 09:17, Daniel Gustafsson  wrote:
> >>
> >>> On 12 Apr 2024, at 23:15, Heikki Linnakangas  wrote:
> >>> Here's a few more. I've accumulate these over the past couple of months, 
> >>> keeping them stashed in a branch, adding to it whenever I've spotted a 
> >>> minor typo while reading the code.
> >>
> >> Nice, let's lot all these together.
> >
> > Here are a few additional ones to add to that.
>
> Thanks.  Collecting all the ones submitted here, as well as a few submitted
> off-list by Alexander, the patch is now a 3-part patchset of cleanups:
>
> 0001 contains the typos and duplicate words fixups, 0002 fixes a parameter 
> with
> the wrong name in the prototype and 0003 removes a leftover prototype which 
> was
> accidentally left in a refactoring.

I realized two small typos: 'sgmr' -> 'smgr'. You may want to include
them in 0001.

-- 
Regards,
Nazir Bilal Yavuz
Microsoft

Re: Typos in the code and README

[Daniel Gustafsson]

> On 16 Apr 2024, at 15:37, Nazir Bilal Yavuz  wrote:

> I realized two small typos: 'sgmr' -> 'smgr'. You may want to include
> them in 0001.

Thanks, I incorporated these into 0001 before pushing.  All the commits in this
patchset are now applied.

--
Daniel Gustafsson

Re: Typos in the code and README

[David Rowley]

On Fri, 19 Apr 2024 at 20:13, Daniel Gustafsson  wrote:
> Thanks, I incorporated these into 0001 before pushing.  All the commits in 
> this
> patchset are now applied.

Here are a few more to see if it motivates anyone else to do a more
thorough search for another batch.

Fixes duplicate words spanning multiple lines plus an outdated
reference to "streaming read" which was renamed to "read stream" late
in that patch's development.

duplicate words found using:
ag "\s([a-zA-Z]{2,})[\s*]*\n\1\b"
ag "\s([a-zA-Z]{2,})\n(\s*\*\s*)\1\b"

David
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 4a4cf76269..32e7d3c146 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -1122,7 +1122,7 @@ heap_beginscan(Relation relation, Snapshot snapshot,
/*
 * Set up a read stream for sequential scans and TID range scans. This
 * should be done after initscan() because initscan() allocates the
-* BufferAccessStrategy object passed to the streaming read API.
+* BufferAccessStrategy object passed to the read stream API.
 */
if (scan->rs_base.rs_flags & SO_TYPE_SEQSCAN ||
scan->rs_base.rs_flags & SO_TYPE_TIDRANGESCAN)
diff --git a/src/backend/access/heap/vacuumlazy.c 
b/src/backend/access/heap/vacuumlazy.c
index de109acc89..0c5379666b 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -13,7 +13,7 @@
  * autovacuum_work_mem) memory space to keep track of dead TIDs.  If the
  * TID store is full, we must call lazy_vacuum to vacuum indexes (and to vacuum
  * the pages that we've pruned). This frees up the memory space dedicated to
- * to store dead TIDs.
+ * store dead TIDs.
  *
  * In practice VACUUM will often complete its initial pass over the target
  * heap relation without ever running out of space to store TIDs.  This means
diff --git a/src/backend/catalog/namespace.c b/src/backend/catalog/namespace.c
index 4548a91723..a2510cf80c 100644
--- a/src/backend/catalog/namespace.c
+++ b/src/backend/catalog/namespace.c
@@ -108,7 +108,7 @@
  * (if one exists).
  *
  * activeSearchPath is always the actually active path; it points to
- * to baseSearchPath which is the list derived from namespace_search_path.
+ * baseSearchPath which is the list derived from namespace_search_path.
  *
  * If baseSearchPathValid is false, then baseSearchPath (and other derived
  * variables) need to be recomputed from namespace_search_path, or retrieved
diff --git a/src/backend/replication/logical/slotsync.c 
b/src/backend/replication/logical/slotsync.c
index cb39adcd0e..ed8104ccb4 100644
--- a/src/backend/replication/logical/slotsync.c
+++ b/src/backend/replication/logical/slotsync.c
@@ -601,7 +601,7 @@ update_and_persist_local_synced_slot(RemoteSlot 
*remote_slot, Oid remote_dbid)
  * metadata of the slot as per the data received from the primary server.
  *
  * The slot is created as a temporary slot and stays in the same state until 
the
- * the remote_slot catches up with locally reserved position and local slot is
+ * remote_slot catches up with locally reserved position and local slot is
  * updated. The slot is then persisted and is considered as sync-ready for
  * periodic syncs.
  *
diff --git a/src/backend/storage/smgr/smgr.c b/src/backend/storage/smgr/smgr.c
index 100f6454e5..a691aed1f4 100644
--- a/src/backend/storage/smgr/smgr.c
+++ b/src/backend/storage/smgr/smgr.c
@@ -244,7 +244,7 @@ smgropen(RelFileLocator rlocator, ProcNumber backend)
 
 /*
  * smgrpin() -- Prevent an SMgrRelation object from being destroyed at end of
- * of transaction
+ * transaction
  */
 void
 smgrpin(SMgrRelation reln)

Re: Typos in the code and README

[Michael Paquier]

On Mon, Sep 02, 2024 at 09:00:00PM +0300, Alexander Lakhin wrote:
> I've gathered another bunch of defects with the possible substitutions.
> Please take a look:
> pgstat_add_kind -> pgstat_register_kind (see 7949d9594)

And here I thought I took care of these inconsistencies.  This one is
on me so I'll go fix that in a bit, with the rest while on it.
--
Michael


signature.asc
Description: PGP signature

Re: Typos in the code and README

[Michael Paquier]

On Tue, Sep 03, 2024 at 02:24:32PM +0900, Michael Paquier wrote:
> On Mon, Sep 02, 2024 at 09:00:00PM +0300, Alexander Lakhin wrote:
> > I've gathered another bunch of defects with the possible substitutions.
> > Please take a look:
> > pgstat_add_kind -> pgstat_register_kind (see 7949d9594)
> 
> And here I thought I took care of these inconsistencies.  This one is
> on me so I'll go fix that in a bit, with the rest while on it.

And done that.

The bit about CommitTSSLRU -> CommitTsSLRU in lwlock.c should be
backpatched down to 17, indeed, but the branch is frozen until the RC
tag lands in the tree, so I have left it out for now. The tag should
show up tomorrow or so.  Good thing that you have noticed this issue
before the release.
--
Michael


signature.asc
Description: PGP signature

Re: Typos in the code and README

[Daniel Gustafsson]

> On 3 Sep 2024, at 07:51, Michael Paquier  wrote:
> 
> On Tue, Sep 03, 2024 at 02:24:32PM +0900, Michael Paquier wrote:
>> On Mon, Sep 02, 2024 at 09:00:00PM +0300, Alexander Lakhin wrote:
>>> I've gathered another bunch of defects with the possible substitutions.
>>> Please take a look:
>>> pgstat_add_kind -> pgstat_register_kind (see 7949d9594)
>> 
>> And here I thought I took care of these inconsistencies.  This one is
>> on me so I'll go fix that in a bit, with the rest while on it.
> 
> And done that.
> 
> The bit about CommitTSSLRU -> CommitTsSLRU in lwlock.c should be
> backpatched down to 17, indeed, but the branch is frozen until the RC
> tag lands in the tree, so I have left it out for now. The tag should
> show up tomorrow or so.  Good thing that you have noticed this issue
> before the release.

I see your v17 typo fixes, and raise you a few more.  Commit 31a98934d169 from
just now contains 2 (out of 3) sets of typos introduced in v17 so they should
follow along when you push the ones mentioned here.

--
Daniel Gustafsson

Re: Typos in the code and README

[Daniel Gustafsson]

> On 4 Sep 2024, at 03:25, Michael Paquier  wrote:
> 
> On Tue, Sep 03, 2024 at 12:00:13PM +0200, Daniel Gustafsson wrote:
>> I see your v17 typo fixes, and raise you a few more.  Commit 31a98934d169 
>> from
>> just now contains 2 (out of 3) sets of typos introduced in v17 so they should
>> follow along when you push the ones mentioned here.
> 
> Is that really mandatory?  I tend to worry about back branches only
> when this stuff is user-visible, like in the docs or error messages.
> This opinion varies for each individual, of course.  That's just my
> lazy opinion.

Not mandatory at all, but since you were prepping a typo backpatch anyways I
figured these could join to put a small dent in reducing risks for future
backports.

--
Daniel Gustafsson

Re: Typos in the code and README

[Michael Paquier]

On Tue, Sep 03, 2024 at 12:00:13PM +0200, Daniel Gustafsson wrote:
> I see your v17 typo fixes, and raise you a few more.  Commit 31a98934d169 from
> just now contains 2 (out of 3) sets of typos introduced in v17 so they should
> follow along when you push the ones mentioned here.

Is that really mandatory?  I tend to worry about back branches only
when this stuff is user-visible, like in the docs or error messages.
This opinion varies for each individual, of course.  That's just my
lazy opinion.

CommitTSSLRU -> CommitTsSLRU is user-visible, showing up in
pg_stat_activity.  Fixed this one with 08b9b9e043bb, as the tag for
17rc1 has been pushed.

Picking f747bc18f7f2 and 75c5231a00f3 on REL_17_STABLE leads to the
attached, I think, without the conflicts.
--
Michael
From f747bc18f7f205795177cce6a93e19169bd0467f Mon Sep 17 00:00:00 2001
From: Michael Paquier 
Date: Tue, 3 Sep 2024 14:49:04 +0900
Subject: [PATCH 1/2] Fix typos and grammar in code comments and docs

Author: Alexander Lakhin
Discussion: https://postgr.es/m/f7e514cf-2446-21f1-a5d2-8c089a6e2...@gmail.com
---
 src/include/utils/injection_point.h| 2 +-
 src/backend/access/transam/multixact.c | 2 +-
 src/backend/executor/execExprInterp.c  | 2 +-
 src/backend/replication/logical/slotsync.c | 2 +-
 src/backend/storage/aio/read_stream.c  | 2 +-
 src/backend/storage/lmgr/lock.c| 2 +-
 src/bin/pg_combinebackup/t/008_promote.pl  | 4 ++--
 src/bin/psql/common.c  | 2 +-
 src/interfaces/libpq/fe-connect.c  | 2 +-
 src/test/subscription/t/021_twophase.pl| 2 +-
 contrib/test_decoding/specs/skip_snapshot_restore.spec | 2 +-
 11 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/src/include/utils/injection_point.h b/src/include/utils/injection_point.h
index 6e417cedc6..8041e4fe0f 100644
--- a/src/include/utils/injection_point.h
+++ b/src/include/utils/injection_point.h
@@ -12,7 +12,7 @@
 #define INJECTION_POINT_H
 
 /*
- * Injections points require --enable-injection-points.
+ * Injection points require --enable-injection-points.
  */
 #ifdef USE_INJECTION_POINTS
 #define INJECTION_POINT(name) InjectionPointRun(name)
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index b7b47ef076..42ea9ba5b4 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2009,7 +2009,7 @@ check_multixact_offset_buffers(int *newval, void **extra, GucSource source)
 }
 
 /*
- * GUC check_hook for multixact_member_buffer
+ * GUC check_hook for multixact_member_buffers
  */
 bool
 check_multixact_member_buffers(int *newval, void **extra, GucSource source)
diff --git a/src/backend/executor/execExprInterp.c b/src/backend/executor/execExprInterp.c
index c32ac7c509..ff76e10bd3 100644
--- a/src/backend/executor/execExprInterp.c
+++ b/src/backend/executor/execExprInterp.c
@@ -4626,7 +4626,7 @@ ExecEvalJsonCoercionFinish(ExprState *state, ExprEvalStep *op)
 	if (SOFT_ERROR_OCCURRED(&jsestate->escontext))
 	{
 		/*
-		 * jsestate->error or jsetate->empty being set means that the error
+		 * jsestate->error or jsestate->empty being set means that the error
 		 * occurred when coercing the JsonBehavior value.  Throw the error in
 		 * that case with the actual coercion error message shown in the
 		 * DETAIL part.
diff --git a/src/backend/replication/logical/slotsync.c b/src/backend/replication/logical/slotsync.c
index ebfbaebe16..fe0478e373 100644
--- a/src/backend/replication/logical/slotsync.c
+++ b/src/backend/replication/logical/slotsync.c
@@ -83,7 +83,7 @@
  * this flag is set. Note that we don't need to reset this variable as after
  * promotion the slot sync worker won't be restarted because the pmState
  * changes to PM_RUN from PM_HOT_STANDBY and we don't support demoting
- * primary without restarting the server. See MaybeStartSlotSyncWorker.
+ * primary without restarting the server. See LaunchMissingBackgroundProcesses.
  *
  * The 'syncing' flag is needed to prevent concurrent slot syncs to avoid slot
  * overwrites.
diff --git a/src/backend/storage/aio/read_stream.c b/src/backend/storage/aio/read_stream.c
index a6c50b2ae2..f04c788a46 100644
--- a/src/backend/storage/aio/read_stream.c
+++ b/src/backend/storage/aio/read_stream.c
@@ -450,7 +450,7 @@ read_stream_begin_relation(int flags,
 	queue_size = max_pinned_buffers + 1;
 
 	/*
-	 * Allocate the object, the buffers, the ios and per_data_data space in
+	 * Allocate the object, the buffers, the ios and per_buffer_data space in
 	 * one big chunk.  Though we have queue_size buffers, we want to be able
 	 * to assume that all the buffers for a single read are contiguous (i.e.
 	 * don't wrap around halfway through), so we allow temporary overflows of
diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c
index 0400a50777..ba77c71baa