MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 14 Jul 2017 16:41:49 +0300
From: Marina Polyakova <m.polyakova@postgrespro.ru>
To: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: PostgreSQL Developers <pgsql-hackers@postgresql.org>, Kevin Grittner
 <kgrittn@gmail.com>, Andres Freund <andres@anarazel.de>, Alvaro Herrera
 <alvherre@2ndquadrant.com>, Thomas Munro <thomas.munro@enterprisedb.com>,
 Robert Haas <robertmhaas@gmail.com>
Subject: Re: WIP Patch: Pgbench Serialization and deadlock errors
Organization: Postgres Professional
In-Reply-To: <alpine.DEB.2.20.1707141344070.20175@lancre>
References: <72a0d590d6ba06f242d75c2e641820ec@postgrespro.ru>
 <alpine.DEB.2.20.1707011607370.6840@lancre>
 <6b4a7fb36c9956595a89a08e5368a9c5@postgrespro.ru>
 <alpine.DEB.2.20.1707031321370.3419@lancre>
 <01df6ca86c78e2c80b4e4d021c99d53a@postgrespro.ru>
 <alpine.DEB.2.20.1707031430380.15247@lancre>
 <f69d534dfada1fdb4767496b7ffc007f@postgrespro.ru>
 <alpine.DEB.2.20.1707121142300.12795@lancre>
 <6ce8613f061001105654673506348c13@postgrespro.ru>
 <alpine.DEB.2.20.1707131818200.20175@lancre>
 <b8aa946758db5d8f1cd3a771e5733d69@postgrespro.ru>
 <alpine.DEB.2.20.1707141344070.20175@lancre>
Message-ID: <0e7afb8c40e9241510947332be8e2ed2@postgrespro.ru>
User-Agent: Roundcube Webmail/1.2.4
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

>>> Not necessarily? It depends on where the locks triggering the issue
>>> are set, if they are all set after the savepoint it could work on a
>>> second attempt.
>> 
>> Don't you mean the deadlock failures where can really help rollback to
> 
> Yes, I mean deadlock failures can rollback to a savepoint and work on
> a second attempt.
> 
>> And could you, please, give an example where a rollback to savepoint 
>> can help to end its subtransaction successfully after a serialization 
>> failure?
> 
> I do not know whether this is possible with about serialization 
> failures.
> It might be if the stuff before and after the savepoint are somehow 
> unrelated...

If you mean, for example, the updates of different tables - a rollback 
to savepoint doesn't help.

And I'm not sure that we should do all the stuff for savepoints 
rollbacks because:
- as I see it now it only makes sense for the deadlock failures;
- if there's a failure what savepoint we should rollback to and start 
the execution again? Maybe to go to the last one, if it is not 
successful go to the previous one etc.
Retrying the entire transaction may take less time..

>> [...] I mean that the sum of transactions with serialization failure 
>> and transactions with deadlock failure can be greater then the totally 
>> sum of transactions with failures.
> 
> Hmmm. Ok.
> 
> A "failure" is a transaction (in the sense of pgbench) that could not
> made it to the end, even after retries. If there is a rollback and the
> a retry which works, it is not a failure.
> 
> Now deadlock or serialization errors, which trigger retries, are worth
> counting as well, although they are not "failures". So my format
> proposal was over optimistic, and the number of deadlocks and
> serializations should better be on a retry count line.
> 
> Maybe something like:
>   ...
>   number of failures: 12 (0.004%)
>   number of retries: 64 (deadlocks: 29, serialization: 35)

Ok! How to you like the idea to use the same format (the total number of 
transactions with failures and the number of retries for each failure 
type) in other places (log, aggregation log, progress) if the values are 
not "default" (= no failures and no retries)?

-- 
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