Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hXYLc-0007j0-S7 for pgsql-hackers@arkaria.postgresql.org; Sun, 02 Jun 2019 21:49:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hXYLb-000149-Ew for pgsql-hackers@arkaria.postgresql.org; Sun, 02 Jun 2019 21:48:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hXYLb-000142-19 for pgsql-hackers@lists.postgresql.org; Sun, 02 Jun 2019 21:48:59 +0000 Received: from mail-io1-xd44.google.com ([2607:f8b0:4864:20::d44]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hXYLW-0004ZA-7p for pgsql-hackers@lists.postgresql.org; Sun, 02 Jun 2019 21:48:57 +0000 Received: by mail-io1-xd44.google.com with SMTP id n5so12700096ioc.7 for ; Sun, 02 Jun 2019 14:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=McXJZBhJogsyt5qgYSg1e7LbhjbLSmivPuujzv8S9u4=; b=z8Wnfi9eiy9Ksp4HxWDsKefIw57PMnpCWONW16YEeNFc7PszWnBsOiipZk3KQzxP0i Gj/9lC6d/m0adpx4eqAK+P6oAQyR8gjIhRB7meu2P5okBUVkCEamci4VGijZJERfHdTC GgQ75bgDtA6NjmKa9ttnZ7mGYlSQVNPjiqLPWVZiEa7Ox2eDFWVN7bxEi9DodkBlvqEs roNR0a12c6AHZeBxG67rFmYcGw4E5SMMBulF/mmjzPZgd3s4UbqBrLmw7XrRcapsySAZ E7osfrGBI02fIvx+UNGvIAISUjTd7Uu6PY1Edbgv8Ig7nvaJepof+HJNQ5QXUdtiPAJG RSPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=McXJZBhJogsyt5qgYSg1e7LbhjbLSmivPuujzv8S9u4=; b=WT19qMnBI2btFuIpdi5J7TAaRzrit8Wz5kaZ69yWBNi67aUBpggMf+sUUjDdMf/7nJ i6ECcc4auLcHYXRzSZiZtwqgDvP6LMJxX3h3BqIS7Lay7yllGQG5XgdDfh+MGm/kXZku jcXhDvI9K+rdlWPbIYPlFZQhe48pgRJZ97jNANNpf84xfenF2GbXrvGn4CGj1Uu0KcM3 uul7NCtGo7RfmC5APZ1HEC0DCsr3CyVZW0jLVVrlOpqu9GXDbuJIdXvVUO/99++jXtbp QJWX3wmz8ZB7+AICxUp+h76wtK8Obg7LDLWWWbjPCbkcVCu/HtKkHZ7Tbwq6WCs5XafT g81w== X-Gm-Message-State: APjAAAWUaoeIHeHjR71RtwYhDMOHj0j5ih9bvo5f6Lyb6GYP60S0gFbD zTiAMaDiMMKVBZ74O88tGlGksg== X-Google-Smtp-Source: APXvYqxd932/vlCeJH7o0Lpmh07CgJH8c1/6N7MdJ2Jxps/k/1YJzZyl9oMZbQ55+YQyP3U2rKCSNw== X-Received: by 2002:a6b:1cc:: with SMTP id 195mr71123iob.87.1559512125846; Sun, 02 Jun 2019 14:48:45 -0700 (PDT) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id 203sm2582186ite.4.2019.06.02.14.48.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Jun 2019 14:48:45 -0700 (PDT) Received: by pryzbyj (Postfix, from userid 1000) id F075C800A8D; Sun, 2 Jun 2019 16:42:57 -0500 (CDT) Date: Sun, 2 Jun 2019 16:42:57 -0500 From: Justin Pryzby To: Andrea Gelmini Cc: pgsql-hackers@lists.postgresql.org, Magnus Hagander , bruce@momjian.us Subject: Re: [PATCH] Simple typos fix Message-ID: <20190602214257.GA17525@telsasoft.com> References: <20190528181718.GA39034@glet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190528181718.GA39034@glet> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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