From: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
---|---|
To: | nagata(at)sraoss(dot)co(dot)jp |
Cc: | pgsql-hackers(at)postgresql(dot)org, coelho(at)cri(dot)ensmp(dot)fr |
Subject: | Re: pgbench: allow to exit immediately when any client is aborted |
Date: | 2023-08-24 00:15:51 |
Message-ID: | 20230824.091551.136833851865484734.t-ishii@sranhm.sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> I start to think this behavior is ok and consistent with previous
>> behavior of pgbench because serialization (and dealock) errors have
>> been treated specially from other types of errors, such as accessing
>> non existing tables. However, I suggest to add more sentences to the
>> explanation of this option so that users are not confused by this.
>>
>> + <varlistentry id="pgbench-option-exit-on-abort">
>> + <term><option>--exit-on-abort</option></term>
>> + <listitem>
>> + <para>
>> + Exit immediately when any client is aborted due to some error. Without
>> + this option, even when a client is aborted, other clients could continue
>> + their run as specified by <option>-t</option> or <option>-T</option> option,
>> + and <application>pgbench</application> will print an incomplete results
>> + in this case.
>> + </para>
>> + </listitem>
>> + </varlistentry>
>> +
>>
>> What about inserting "Note that serialization failures or deadlock
>> failures will not abort client. See <xref
>> linkend="failures-and-retries"/> for more information." into the end
>> of this paragraph?
>
> --exit-on-abort is related to "abort" of a client instead of error or
> failure itself, so rather I wonder a bit that mentioning serialization/deadlock
> failures might be confusing. However, if users may think of such failures from
> "abort", it could be beneficial to add the sentences with some modification as
> below.
I myself confused by this and believe that adding extra paragraph is
beneficial to users.
> "Note that serialization failures or deadlock failures does not abort the
> client, so they are not affected by this option.
> See <xref linkend="failures-and-retries"/> for more information."
"does not" --> "do not".
>> BTW, I think:
>> Exit immediately when any client is aborted due to some error. Without
>>
>> should be:
>> Exit immediately when any client is aborted due to some errors. Without
>>
>> (error vs. erros)
>
> Well, I chose "some" to mean "unknown or unspecified", not "an unspecified amount
> or number of", so singular form "error" is used.
Ok.
> Instead, should we use "due to a error"?
I don't think so.
>> Also:
>> + <option>--exit-on-abort</option> is specified . Otherwise in the worst
>>
>> There is an extra space between "specified" and ".".
>
> Fixed.
>
> Also, I fixed the place of the description in the documentation
> to alphabetical order
>
> Attached is the updated patch.
Looks good to me. If there's no objection, I will commit this next week.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2023-08-24 00:45:38 | Re: pg_rewind WAL segments deletion pitfall |
Previous Message | Peter Smith | 2023-08-23 23:07:55 | Re: pg_upgrade - a function parameter shadows global 'new_cluster' |