A small typo
I found a small typo in a comment in pgbench.c of 15/master.
- * Return the number fo failed transactions.
+ * Return the number of failed transactions.While at it, I found "* lot fo unnecessary work." in pg13's
procsignal.c. It has been fixed by 2a093355aa in PG14 but PG13 was
left alone at the time.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Attachments:
pgbench_comment_type_fix_15_master.patchtext/x-patch; charset=us-asciiDownload
diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index 098fb43b3c..4d5d6560bf 100644
--- a/src/bin/pgbench/pgbench.c
+++ b/src/bin/pgbench/pgbench.c
@@ -4415,7 +4415,7 @@ executeMetaCommand(CState *st, pg_time_usec_t *now)
}
/*
- * Return the number fo failed transactions.
+ * Return the number of failed transactions.
*/
static int64
getFailures(const StatsData *stats)
On Wed, Sep 14, 2022 at 10:46 AM Kyotaro Horiguchi <horikyota.ntt@gmail.com>
wrote:
I found a small typo in a comment in pgbench.c of 15/master.
- * Return the number fo failed transactions. + * Return the number of failed transactions.While at it, I found "* lot fo unnecessary work." in pg13's
procsignal.c. It has been fixed by 2a093355aa in PG14 but PG13 was
left alone at the time.
+1. And grep shows no more this kind of typo in source codes in master.
$ find . -name "*.[ch]" | xargs grep ' fo '
./src/bin/pgbench/pgbench.c: * Return the number fo failed transactions.
Thanks
Richard
On Wed, Sep 14, 2022 at 8:16 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
I found a small typo in a comment in pgbench.c of 15/master.
- * Return the number fo failed transactions. + * Return the number of failed transactions.
LGTM.
While at it, I found "* lot fo unnecessary work." in pg13's
procsignal.c. It has been fixed by 2a093355aa in PG14 but PG13 was
left alone at the time.
I think sometimes we fix typos only in HEAD. I am not sure if we have
a clear policy to backpatch such things.
--
With Regards,
Amit Kapila.
Amit Kapila <amit.kapila16@gmail.com> writes:
On Wed, Sep 14, 2022 at 8:16 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:I found a small typo in a comment in pgbench.c of 15/master. - * Return the number fo failed transactions. + * Return the number of failed transactions.
LGTM.
+1
While at it, I found "* lot fo unnecessary work." in pg13's
procsignal.c. It has been fixed by 2a093355aa in PG14 but PG13 was
left alone at the time.
I think sometimes we fix typos only in HEAD. I am not sure if we have
a clear policy to backpatch such things.
I would not go back and change v13 at this point. You're right
that this is fuzzy, but overriding the contemporaneous decision
not to backpatch seems well outside our usual habits.
There are basically two good reasons to back-patch comment changes:
* fear that the comment is wrong enough to mislead people looking
at the older branch;
* fear that leaving it alone will create a merge hazard for future
back-patches.
It doesn't seem to me that either of those is a strong concern
in this case. In the absence of these concerns, back-patching
seems like make-work (and useless expenditure of buildfarm
cycles).
regards, tom lane
On Wed, Sep 14, 2022 at 9:10 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Amit Kapila <amit.kapila16@gmail.com> writes:
There are basically two good reasons to back-patch comment changes:
* fear that the comment is wrong enough to mislead people looking
at the older branch;* fear that leaving it alone will create a merge hazard for future
back-patches.It doesn't seem to me that either of those is a strong concern
in this case. In the absence of these concerns, back-patching
seems like make-work (and useless expenditure of buildfarm
cycles).
Agreed. I'll push this to HEAD after some time.
--
With Regards,
Amit Kapila.
At Wed, 14 Sep 2022 09:19:22 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in
On Wed, Sep 14, 2022 at 9:10 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Amit Kapila <amit.kapila16@gmail.com> writes:
There are basically two good reasons to back-patch comment changes:
* fear that the comment is wrong enough to mislead people looking
at the older branch;* fear that leaving it alone will create a merge hazard for future
back-patches.It doesn't seem to me that either of those is a strong concern
in this case. In the absence of these concerns, back-patching
seems like make-work (and useless expenditure of buildfarm
cycles).Agreed. I'll push this to HEAD after some time.
Thanks for committing, and for the clarification about back-patching
policy!
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center