Обсуждение: [MASSMAIL]Typos in the code and README

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).

--
Daniel Gustafsson

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

On Thu, Apr 11, 2024 at 03:37:00PM +0200, Daniel Gustafsson wrote:
>     On 11 Apr 2024, at 15:29, David Rowley <dgrowleyml@gmail.com> wrote:
> 
>     On Fri, 12 Apr 2024, 1:05 am Daniel Gustafsson, <daniel@yesql.se> 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  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.

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 <dgrowleyml@gmail.com> wrote:
> > 
> >     On Fri, 12 Apr 2024, 1:05 am Daniel Gustafsson, <daniel@yesql.se> 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  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.

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)

> On 12 Apr 2024, at 23:15, Heikki Linnakangas <hlinnaka@iki.fi> 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
itwhenever I've spotted a minor typo while reading the code. 

Nice, let's lot all these together.

--
Daniel Gustafsson

On Sat, 13 Apr 2024 at 09:17, Daniel Gustafsson <daniel@yesql.se> wrote:
>
> > On 12 Apr 2024, at 23:15, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> > Here's a few more. I've accumulate these over the past couple of months, keeping them stashed in a branch, adding
toit 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

> On 14 Apr 2024, at 13:19, David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Sat, 13 Apr 2024 at 09:17, Daniel Gustafsson <daniel@yesql.se> wrote:
>>
>>> On 12 Apr 2024, at 23:15, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>>> Here's a few more. I've accumulate these over the past couple of months, keeping them stashed in a branch, adding
toit 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

Hi,

Thanks for working on this!

On Mon, 15 Apr 2024 at 15:26, Daniel Gustafsson <daniel@yesql.se> wrote:
>
> > On 14 Apr 2024, at 13:19, David Rowley <dgrowleyml@gmail.com> wrote:
> >
> > On Sat, 13 Apr 2024 at 09:17, Daniel Gustafsson <daniel@yesql.se> wrote:
> >>
> >>> On 12 Apr 2024, at 23:15, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> >>> Here's a few more. I've accumulate these over the past couple of months, keeping them stashed in a branch, adding
toit 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

> On 16 Apr 2024, at 15:37, Nazir Bilal Yavuz <byavuz81@gmail.com> 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

On Fri, 19 Apr 2024 at 20:13, Daniel Gustafsson <daniel@yesql.se> 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

On Sat, 20 Apr 2024 at 16:09, David Rowley <dgrowleyml@gmail.com> 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

Hello,

28.04.2024 11:05, David Rowley wrote:

> On Sat, 20 Apr 2024 at 16:09, David Rowley <dgrowleyml@gmail.com> 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,
Alexander

On Fri, 3 May 2024 at 00:00, Alexander Lakhin <exclusion@gmail.com> 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

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,
Alexander

> On 4 Jul 2024, at 19:00, Alexander Lakhin <exclusion@gmail.com> 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

(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 <exclusion@gmail.com> 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

> On 3 Sep 2024, at 07:51, Michael Paquier <michael@paquier.xyz> 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

> On 4 Sep 2024, at 03:25, Michael Paquier <michael@paquier.xyz> 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

On Wed, 4 Sept 2024 at 20:24, Daniel Gustafsson <daniel@yesql.se> wrote:
> 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.

I think this is pretty good logic.  I think fixing comment typos in
ancient code and backpatching to all supported versions isn't good use
of time, but fixing a typo in "recent" code and backpatching to where
that code was added seems useful. Newer code is more likely to need
bug fixes in the future, so going to a bit more effort to make
backpatching those bug fixes easier seems worth the effort.  I just
don't know what "recent" should be defined as. I'd say if it's in a
version we've not released yet, that's probably recent. By the time .1
is out, there's less chance of bugs in new code. Anyway, I doubt hard
guidelines are warranted here, but maybe some hints about best
practices in https://wiki.postgresql.org/wiki/Committing_checklist ?

David

> On 4 Sep 2024, at 17:34, David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Wed, 4 Sept 2024 at 20:24, Daniel Gustafsson <daniel@yesql.se> wrote:
>> 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.
>
> I think this is pretty good logic.  I think fixing comment typos in
> ancient code and backpatching to all supported versions isn't good use
> of time, but fixing a typo in "recent" code and backpatching to where
> that code was added seems useful. Newer code is more likely to need
> bug fixes in the future, so going to a bit more effort to make
> backpatching those bug fixes easier seems worth the effort.

Absolutely agree.

> I just don't know what "recent" should be defined as. I'd say if it's in a
> version we've not released yet, that's probably recent. By the time .1
> is out, there's less chance of bugs in new code. Anyway, I doubt hard
> guidelines are warranted here, but maybe some hints about best
> practices in https://wiki.postgresql.org/wiki/Committing_checklist ?

That sounds like a good idea.  Off the cuff I would agree that unreleased
versions and .0 versions are strong candidates (but not mandatory) for trivial
backpatches like typos, beyond that the value is likely to be lower.

--
Daniel Gustafsson

On Thu, 2 Jan 2025 at 05:00, Alexander Lakhin <exclusion@gmail.com> wrote:
> Please look at another collection of typos and inconsistencies introduced
> during 2024:

The fixes all look good to me. I see some are mine, so I will take
care of pushing.

Thanks for the patch.

David

Hello hackers,

I've gathered the following collection of typos and inconsistencies
appeared since 2025-01-01:
aio_worker.c -> method_worker.c

amcheck_lock_relation -> amcheck_lock_relation_and_check

be_key -> be_cancel_key

belonds -> belongs

cann -> can

CheckConstraintFetch -> CheckNNConstraintFetch
(renamed by a379061a2)

COLLID -> COLLOID

coltypemods -> coltypmods

columsn -> column

combinig -> combining

containting -> containing

non-exist datbase -> non-existent database

dead_end -> dead-end
(see a78af0427)

derefefence -> dereference

displyed -> displayed

droping -> dropping

es_eqp_active -> es_epq_active

es_part_prune_result -> es_part_prune_results

ExceDelete -> ExecDelete

excludes-chema -> exclude-schema

it fhe -> if the

GIN_TUPLE_ -> GIN_TUPLE_H

HandleFatalErrors -> HandleFatalError

happend -> reached
(to preserve the line width)

happenning -> happening

HIKEY -> P_HIKEY

IGNORE_CHECKSUM_FAILURE -> PIV_IGNORE_CHECKSUM_FAILURE

InitExecPartitionPruneContext -> InitExecPartitionPruneContexts

inititalization -> initialization

Injection_point -> Injection point

iterm -> item

$log_end -> remove unused variable
(align with src/test/modules/oauth_validator/t/001_server.pl)

looplback -> loopback

mappping -> mapping

MyWorkerId -> MyIoWorkerId

negotation -> negotiation

network-byte-order -> network byte order

parititioned* -> partitioned*

pending_null -> pending_nulls

permanentaly -> permanently

pg_localeconf_free -> pg_localeconv_free

PG_READ_ALL_STATS -> ROLE_PG_READ_ALL_STATS

pk_strategy -> pk_cmptype
(see 8123e91f5)

PM_WAIT_BACKEND -> PM_WAIT_BACKENDS

pollset -> poll set

predicable -> predictable

PRINT_STATS_STDERR -> PRINT_STATS_TO_STDERR

procced -> proceed

remining -> remaining

save_xmin -> saved_xmin

smgstartreadv -> smgrstartreadv

StartLocalBufer -> StartLocalBufferIO

statitistics -> statistics

swaping -> swapping

synq_queue_destroy -> sync_queue_destroy

thats -> that's

ther -> there

test-server -> test server

unfronzen -> unfrozen

upin -> unpin

Please find attached the complete patch for your convenience.

Best regards,
Alexander Lakhin
Neon (https://neon.tech)

On Sat, Apr 19, 2025 at 11:00:00AM +0300, Alexander Lakhin wrote:
> I've gathered the following collection of typos and inconsistencies
> appeared since 2025-01-01:

Good finds, Alexander, particularly for the set of function and
variable names used in the comments that do not match with the
reality.  I've checked all these, and they're good for me.

> GIN_TUPLE_ -> GIN_TUPLE_H

This one is interested.  It should be harmless in practice, but it
could cause conflicts in theory.
--
Michael

GIN_TUPLE_ -> GIN_TUPLE_H

This one is interested.  It should be harmless in practice, but it
could cause conflicts in theory.
--

On Sat, 19 Apr 2025 at 20:00, Alexander Lakhin <exclusion@gmail.com> wrote:
> I've gathered the following collection of typos and inconsistencies
> appeared since 2025-01-01:

Here are a few more fixes of a similar ilk. All new in 2025,
predominantly from the last few days before feature freeze.

The few I wasn't a full 100% certain on were "big big" *could* be used
as an adjective, but "huge" or "massive" would have been better. I
didn't see the need so assumed it was a mistake. The "now now"
technically is ok in South Africa [1], but I don't believe that
meaning was the intention.

I found these with a manual trawl through:

git grep -E "\b(\w+[^long|^that]+)\s+\1\b" -- ':!*.po' ':!*.out'
':!*.data' ':!*.dat' ':!*.xml'

David

[1] https://en.wikipedia.org/wiki/List_of_South_African_slang_words

On Sun, 20 Apr 2025 at 13:32, David Rowley <dgrowleyml@gmail.com> wrote:
> Here are a few more fixes of a similar ilk. All new in 2025,
> predominantly from the last few days before feature freeze.

I've pushed those ones.

David

On Mon, Apr 21, 2025 at 10:42:19AM +1200, David Rowley wrote:
> On Sun, 20 Apr 2025 at 13:32, David Rowley <dgrowleyml@gmail.com> wrote:
>> Here are a few more fixes of a similar ilk. All new in 2025,
>> predominantly from the last few days before feature freeze.
>
> I've pushed those ones.

Thanks for sharing the command able to spot all these.
--
Michael

On Mon, 21 Apr 2025 at 11:21, Michael Paquier <michael@paquier.xyz> wrote:
> Thanks for sharing the command able to spot all these.

I just pushed a few more. The previous regex didn't account for the
duplicate word being on the next line. I dug up the following to find
the ones just committed in 78eda9e26.

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

cd doc
ag "\s([a-zA-Z]{1,})[\s*]*\n\s+\1\b"

David

Hello hackers,

Please look at another collection of typos, inconsistencies, and lost
entities (most of them introduced in 2025, but not all). In passing, I'm
proposing to synchronize parameter names in function declarations with
implementations.

Typos:
all-forzen -> all-frozen
Historcally -> Historically
insallation -> installation
maintanence_work_mem -> maintenance_work_mem
ndicates -> indicates
noacess -> noaccess
parititoned -> partititoned

Inconsistent spelling:
brin_wi_index -> brin_wi_idx
bufhdr -> bufHdr
FullTransactionID -> FullTransactionId
GroupExprInfos - > GroupingExprInfos
HEAP_PRUNE_FREEZE -> HEAP_PAGE_PRUNE_FREEZE (per 1937ed706)
inferPredExprs -> inferIndexExprs
newRightLink -> newRightlink
paramtypmode -> paramtypmod
pg_stat_replication_slot -> pg_stat_replication_slots
READ_WRITE_PARSE_PLAN_TREES -> WRITE_READ_PARSE_PLAN_TREES
DEFAULT_DEBUG_READ_WRITE_PARSE_PLAN_TREES -> DEFAULT_DEBUG_WRITE_READ_PARSE_PLAN_TREES
ReloptInfo -> RelOptInfo
retain_conflict_info -> retain_dead_tuples (see a850be2fe)
TIDStore -> TidStore

Inconsistent parameter naming:
RangeVarCallbackForStats(..., Oid oldRelid, ...) -> RangeVarCallbackForStats(..., Oid oldRelId, ...)
heap_lock_updated_tuple(..., TransactionId prior_rawxmax, ...) -> heap_lock_updated_tuple(..., TransactionId 
prior_raw_xmax, ...)
StartupLogicalDecodingStatus(bool status_in_control_file) -> StartupLogicalDecodingStatus(bool last_status)
FetchRelationStates(..., bool *has_pending_sequences, ...) -> FetchRelationStates(..., bool *has_pending_subsequences,
...)
PredicateLockTwoPhaseFinish(FullTransactionId xid, -> PredicateLockTwoPhaseFinish(FullTransactionId fxid,
PredicateLockTwoPhaseFinish(TransactionId xid, -> PredicateLockTwoPhaseFinish(FullTransactionId fxid,
SetSequence(Oid relid, int64 next, bool is_called) -> SetSequence(Oid relid, int64 next, bool iscalled)
fdatasync(int fildes) -> fdatasync(int fd)
gai_strerror(int ecode) -> gai_strerror(int errcode)
llvm_copy_attributes(LLVMValueRef from, LLVMValueRef to) -> llvm_copy_attributes(LLVMValueRef v_from, LLVMValueRef
v_to)
ox1(PlannerInfo *root, Gene *mom, Gene *dad, ...) -> ox1(PlannerInfo *root, Gene *tour1, Gene *tour2, ...)
ox2(PlannerInfo *root, Gene *mom, Gene *dad, ...) -> ox2(PlannerInfo *root, Gene *tour1, Gene *tour2, ...)
pg_pread(..., size_t nbyte, ...) -> pg_pread(..., size_t size, ...)
pg_pwrite(..., size_t nbyte, ...) -> pg_pwrite(..., size_t size, ...)
pgwin32_connect(..., int namelen) -> pgwin32_connect(..., int addrlen)
replace_s(..., int * adjustment) -> replace_s(..., int * adjptr)

There is also
extern int        pgwin32_recv(SOCKET s, char *buf, int len, int flags);
vs
pgwin32_recv(SOCKET s, char *buf, int len, int f)
but I've left at as-is; probably the change should be made in the
implementation...

Orphan entities:
CheckXLogLogicalInfo -> remove (came with 67c20979c [1])
HAVE_ATOMIC_H, HAVE_MBARRIER_H -> remove (per 25f36066d)
#ifdef BS_DEBUG in contrib/ltree/ltxtquery_io.c -> remove (introduced with 1dedbf2da)

The patch is attached for your convenience.

[1] The implementation was removed in v34-0001-Toggle-*.patch:
https://www.postgresql.org/message-id/flat/CAD21AoCVLeLYq09pQPaWs%2BJwdni5FuJ8v2jgq-u9_uFbcp6UbA%40mail.gmail.com

Best regards,
Alexander

On Thu, Jan 01, 2026 at 10:00:00AM +0200, Alexander Lakhin wrote:
> READ_WRITE_PARSE_PLAN_TREES -> WRITE_READ_PARSE_PLAN_TREES
> DEFAULT_DEBUG_READ_WRITE_PARSE_PLAN_TREES -> DEFAULT_DEBUG_WRITE_READ_PARSE_PLAN_TREES

I thought that this was a bug first, but we also use this name for the
default value.

> replace_s(..., int * adjustment) -> replace_s(..., int * adjptr)

Updating this one contradicts with the upstream sources, see
b464e51ab32f that has done the opposite switch.

> There is also
> extern int        pgwin32_recv(SOCKET s, char *buf, int len, int flags);
> vs
> pgwin32_recv(SOCKET s, char *buf, int len, int f)
> but I've left at as-is; probably the change should be made in the
> implementation...

Using "flags" would be confusing I think as things stand, the code
casts a DWORD with the same name.

> Orphan entities:
> HAVE_ATOMIC_H, HAVE_MBARRIER_H -> remove (per 25f36066d)

Indeed..  It seems slightly cleaner to remove these separately.  Will
do so.

> #ifdef BS_DEBUG in contrib/ltree/ltxtquery_io.c -> remove (introduced with 1dedbf2da)

I am wondering if BS stands for what it means or if it's something
else..
--
Michael

Michael Paquier <michael@paquier.xyz> writes:
> On Thu, Jan 01, 2026 at 10:00:00AM +0200, Alexander Lakhin wrote:
>> replace_s(..., int * adjustment) -> replace_s(..., int * adjptr)

> Updating this one contradicts with the upstream sources, see
> b464e51ab32f that has done the opposite switch.

It looks like upstream has fixed the problem -- not by making the
two instances match, but by removing the parameter altogether
(see their recent commit 16edd5abb9ce7386e9208b998cd43524480cb801).

Maybe it's time for another sync with upstream?  But if we don't
feel like doing that right now, I think Alexander's proposed patch
is okay.  It won't make the next sync any harder.

            regards, tom lane

On Sun, Jan 04, 2026 at 06:32:14PM -0500, Tom Lane wrote:
> It looks like upstream has fixed the problem -- not by making the
> two instances match, but by removing the parameter altogether
> (see their recent commit 16edd5abb9ce7386e9208b998cd43524480cb801).

Ah, you mean as in [1] as mentioned in [2].  I didn't know this part.
A new sync sounds like a good idea.  I am not sure to see a point in
changing the same thing twice, so...

> Maybe it's time for another sync with upstream?

This sounds like a good idea to me.  The last sync has been done in
February 2025, so it could be done in the next couple of weeks.

[1]: https://github.com/snowballstem/snowball.git
[2]: https://snowballstem.org/download.html
--
Michael

Michael Paquier <michael@paquier.xyz> writes:
> On Sun, Jan 04, 2026 at 06:32:14PM -0500, Tom Lane wrote:
>> Maybe it's time for another sync with upstream?

> This sounds like a good idea to me.  The last sync has been done in
> February 2025, so it could be done in the next couple of weeks.

I can look into that tomorrow or so, if there's not objections.
It looks like nothing exciting has gone into snowball in the last
month or so, so right now might be a good time to sync.

            regards, tom lane

Hi,

On 2026-01-01 10:00:00 +0200, Alexander Lakhin wrote:
> bufhdr -> bufHdr

I just ran into this one due to a rebase conflict. Obviously trivial to
resolve. But what's the point of this change?  If you wanted to fix the
arguably wrong name, it'd have to be "buf" or "BufferDesc", as there's no
variable named either bufhdr or bufHdr.

Having random stuff mixed into these changes is one of the reasons why I so
dislike them.

Greetings,

Andres Freund

Hi,

On 2026-01-04 18:32:14 -0500, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
> > On Thu, Jan 01, 2026 at 10:00:00AM +0200, Alexander Lakhin wrote:
> >> replace_s(..., int * adjustment) -> replace_s(..., int * adjptr)
> 
> > Updating this one contradicts with the upstream sources, see
> > b464e51ab32f that has done the opposite switch.
> 
> It looks like upstream has fixed the problem -- not by making the
> two instances match, but by removing the parameter altogether
> (see their recent commit 16edd5abb9ce7386e9208b998cd43524480cb801).
> 
> Maybe it's time for another sync with upstream?  But if we don't
> feel like doing that right now, I think Alexander's proposed patch
> is okay.  It won't make the next sync any harder.

Your recent commit unfortunately doesn't build with meson, due to headers now
not just residing in src/include/snowball/ but also
src/include/snowball/libstemmer/.

The fix is trivial - happy to push it if you want?

Greetings,

Andres

Andres Freund <andres@anarazel.de> writes:
> Your recent commit unfortunately doesn't build with meson, due to headers now
> not just residing in src/include/snowball/ but also
> src/include/snowball/libstemmer/.

Yeah --- but that was true before too.  I don't quite see how
it built under meson before.

            regards, tom lane

Hi,

On 2026-01-05 16:43:02 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > Your recent commit unfortunately doesn't build with meson, due to headers now
> > not just residing in src/include/snowball/ but also
> > src/include/snowball/libstemmer/.
> 
> Yeah --- but that was true before too.  I don't quite see how
> it built under meson before.

Previously the only thing including snowball/libstemmer/*h files was
src/backend/snowball/dict_snowball.c, which included them relative to
src/includ. But now they are also included from
src/backend/snowball/libstemmer/stem_*.c, just as
> #include "stem_*.h"
thereby requiring include/snowball/libstemmer to be an include path.

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:
> On 2026-01-05 16:43:02 -0500, Tom Lane wrote:
>> Yeah --- but that was true before too.  I don't quite see how
>> it built under meson before.

> Previously the only thing including snowball/libstemmer/*h files was
> src/backend/snowball/dict_snowball.c, which included them relative to
> src/includ. But now they are also included from
> src/backend/snowball/libstemmer/stem_*.c,

Oh, you're right.  So it worked without any Makefile changes because
the Makefile already had

override CPPFLAGS := -I$(top_srcdir)/src/include/snowball \
    -I$(top_srcdir)/src/include/snowball/libstemmer $(CPPFLAGS)

but meson.build had failed to duplicate that.

            regards, tom lane

On Mon, Jan 05, 2026 at 11:00:00PM +0400, Alexander Law wrote:
> I thought that the initial spelling was meant to reference bufHdr variable
> as if it was declared locally as we can see this name in other functions in
> bufmgr.c (at 5d508736).

Yeah, I was under the same impression as yours.  The older pattern
could not be found in the tree, the new one is all spread around.

> By the way, I've just noticed that I fixed only one out of two typos in
> "parititoned", so it's still spelled wrong: "partititoned". Sorry.

Meh.  And here I thought that I read all these diffs correctly.  Will
adjust in a bit.
--
Michael

Hi,

On 2026-01-06 12:27:29 +0900, Michael Paquier wrote:
> On Mon, Jan 05, 2026 at 11:00:00PM +0400, Alexander Law wrote:
> > I thought that the initial spelling was meant to reference bufHdr variable
> > as if it was declared locally as we can see this name in other functions in
> > bufmgr.c (at 5d508736).
> 
> Yeah, I was under the same impression as yours.  The older pattern
> could not be found in the tree, the new one is all spread around.

Sure, but that function doesn't use bufHdr, making the new phrasing just as
confusing as the old one.

Greetings,

Andres