MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Fri, 16 Jun 2017 13:31:27 +0300
From: Marina Polyakova <m.polyakova@postgrespro.ru>
To: Kevin Grittner <kgrittn@gmail.com>, Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@2ndquadrant.com>,
 Thomas Munro <thomas.munro@enterprisedb.com>
Subject: Re: WIP Patch: Pgbench Serialization and deadlock errors
Organization: Postgres Professional
In-Reply-To: 
 <CACjxUsOfbn72EaH4i_OuzdY-0PUYfg1Y3o8G27tEA8fJOaPQEw@mail.gmail.com>
References: <72a0d590d6ba06f242d75c2e641820ec@postgrespro.ru>
 <20170615191636.mqzk7ongddmhoqzm@alap3.anarazel.de>
 <CACjxUsOfbn72EaH4i_OuzdY-0PUYfg1Y3o8G27tEA8fJOaPQEw@mail.gmail.com>
Message-ID: <bcfec2e7ebd6dc741b85650456068914@postgrespro.ru>
User-Agent: Roundcube Webmail/1.2.4
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

>>> P.S. Does this use case (do not retry transaction with serialization 
>>> or
>>> deadlock failure) is most interesting or failed transactions should 
>>> be
>>> retried (and how much times if there seems to be no hope of 
>>> success...)?
>> 
>> I can't quite parse that sentence, could you restate?
> 
> The way I read it was that the most interesting solution would retry
> a transaction from the beginning on a serialization failure or
> deadlock failure.  Most people who use serializable transactions (at
> least in my experience) run though a framework that does that
> automatically, regardless of what client code initiated the
> transaction.  These retries are generally hidden from the client
> code -- it just looks like the transaction took a bit longer.
> Sometimes people will have a limit on the number of retries.  I
> never used such a limit and never had a problem, because our
> implementation of serializable transactions will not throw a
> serialization failure error until one of the transactions involved
> in causing it has successfully committed -- meaning that the retry
> can only hit this again on a *new* set of transactions.
> 
> Essentially, the transaction should only count toward the TPS rate
> when it eventually completes without a serialization failure.
> 
> Marina, did I understand you correctly?

Álvaro Herrera in next message of this thread has understood my text 
right:

> As far as I understand her proposal, it is exactly the opposite -- if a
> transaction fails, it is discarded.  And this P.S. note is asking
> whether this is a good idea, or would we prefer that failing
> transactions are retried.

And thank you very much for your explanation how and why transactions 
with failures should be retried! I'll try to implement all of it.

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