Re: [PATCH] Simple typos fix

Thanks for finding these ; I think a few hunks are false positives and should
be removed. A few more are debatable and could be correct either way:

Kazakstan
alloced - not an English word, but a technical one;
delink - "unlink" is better for the filesystem operation, but I don't think "delink" is wrong for a list operation.
dependees (?)
This'd
define'd

On Tue, May 28, 2019 at 08:17:18PM +0200, Andrea Gelmini wrote:
> diff --git a/contrib/amcheck/verify_nbtree.c b/contrib/amcheck/verify_nbtree.c
> index de0a98f6d9..ff13b0c9e7 100644
> --- a/contrib/amcheck/verify_nbtree.c
> +++ b/contrib/amcheck/verify_nbtree.c
> @@ -1278,7 +1278,7 @@ bt_right_page_check_scankey(BtreeCheckState *state)
> * Routines like _bt_search() don't require *any* page split interlock
> * when descending the tree, including something very light like a buffer
> * pin. That's why it's okay that we don't either. This avoidance of any
> - * need to "couple" buffer locks is the raison d' etre of the Lehman & Yao
> + * need to "couple" buffer locks is the reason d'etre of the Lehman & Yao

I think this is wrong. The French phase is "raison d'etre".

> diff --git a/src/backend/replication/logical/reorderbuffer.c b/src/backend/replication/logical/reorderbuffer.c
> index e7c32f2a13..20bb928016 100644
> --- a/src/backend/replication/logical/reorderbuffer.c
> +++ b/src/backend/replication/logical/reorderbuffer.c
> @@ -2279,7 +2279,7 @@ ReorderBufferSerializeTXN(ReorderBuffer *rb, ReorderBufferTXN *txn)
>
> /*
> * store in segment in which it belongs by start lsn, don't split over
> - * multiple segments tho
> + * multiple segments to

I think this is wrong. It should say "though". Or perhaps:
* store at segment to which its start lsn belongs, but don't split over
* multiple segments

> diff --git a/src/backend/utils/cache/relmapper.c b/src/backend/utils/cache/relmapper.c
> index 3b4f21bc54..403435df52 100644
> --- a/src/backend/utils/cache/relmapper.c
> +++ b/src/backend/utils/cache/relmapper.c
> @@ -146,7 +146,7 @@ static void perform_relmap_update(bool shared, const RelMapFile *updates);
> /*
> * RelationMapOidToFilenode
> *
> - * The raison d' etre ... given a relation OID, look up its filenode.
> + * The reason d'etre... given a relation OID, look up its filenode.

Wrong

> @@ -907,7 +907,7 @@ write_relmap_file(bool shared, RelMapFile *newmap,
> * Make sure that the files listed in the map are not deleted if the outer
> * transaction aborts. This had better be within the critical section
> * too: it's not likely to fail, but if it did, we'd arrive at transaction
> - * abort with the files still vulnerable. PANICing will leave things in a
> + * abort with the files still vulnerable. Panicking will leave things in a

Wrong ?

Thanks,
Justin