From: Marina Polyakova <m.polyakova@postgrespro.ru>
To: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: PostgreSQL Developers <pgsql-hackers@postgresql.org>
Subject: Re: WIP Patch: Pgbench Serialization and deadlock errors
Date: Mon, 03 Jul 2017 15:07:11 +0300
Message-ID: <01df6ca86c78e2c80b4e4d021c99d53a@postgrespro.ru> (raw)
In-Reply-To: <alpine.DEB.2.20.1707031321370.3419@lancre>
References: <72a0d590d6ba06f242d75c2e641820ec@postgrespro.ru>
<alpine.DEB.2.20.1707011607370.6840@lancre>
<6b4a7fb36c9956595a89a08e5368a9c5@postgrespro.ru>
<alpine.DEB.2.20.1707031321370.3419@lancre>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
> The current error handling is either "close connection" or maybe in
> some cases even "exit". If this is changed, then the client may
> continue execution in some unforseen state and behave unexpectedly.
> We'll see.
Thanks, now I understand this.
>>> ISTM that the retry implementation should be implemented somehow in
>>> the automaton, restarting the same script for the beginning.
>>
>> If there are several transactions in this script - don't you think
>> that we should restart only the failed transaction?..
>
> On some transaction failures based on their status. My point is that
> the retry process must be implemented clearly with a new state in the
> client automaton. Exactly when the transition to this new state must
> be taken is another issue.
About it, I agree with you that it should be done in this way.
>>> The number of retries and maybe failures should be counted, maybe
>>> with
>>> some adjustable maximum, as suggested.
>>
>> If we fix the maximum number of attempts the maximum number of
>> failures for one script execution will be bounded above
>> (number_of_transactions_in_script * maximum_number_of_attempts). Do
>> you think we should make the option in program to limit this number
>> much more?
>
> Probably not. I think that there should be a configurable maximum of
> retries on a transaction, which may be 0 by default if we want to be
> upward compatible with the current behavior, or maybe something else.
I propose the option --max-attempts-number=NUM which NUM cannot be less
than 1. I propose it because I think that, for example,
--max-attempts-number=100 is better than --max-retries-number=99. And
maybe it's better to set its default value to 1 too because retrying of
shell commands can produce new errors..
>>> In doLog, added columns should be at the end of the format.
>>
>> I have inserted it earlier because these columns are not optional. Do
>> you think they should be optional?
>
> I think that new non-optional columns it should be at the end of the
> existing non-optional columns so that existing scripts which may
> process the output may not need to be updated.
Thanks, I agree with you :)
>>> I'm not sure that there should be an new option to report failures,
>>> the information when relevant should be integrated in a clean format
>>> into the existing reports... Maybe the "per command latency"
>>> report/option should be renamed if it becomes more general.
>>
>> I have tried do not change other parts of program as much as possible.
>> But if you think that it will be more useful to change the option I'll
>> do it.
>
> I think that the option should change if its naming becomes less
> relevant, which is to be determined. AFAICS, ISTM that new measures
> should be added to the various existing reports unconditionnaly (i.e.
> without a new option), so maybe no new option would be needed.
Thanks! I didn't think about it in this way..
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: m.polyakova@postgrespro.ru, coelho@cri.ensmp.fr
Subject: Re: WIP Patch: Pgbench Serialization and deadlock errors
In-Reply-To: <01df6ca86c78e2c80b4e4d021c99d53a@postgrespro.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox