From: | Marina Polyakova <m(dot)polyakova(at)postgrespro(dot)ru> |
---|---|
To: | Kevin Grittner <kgrittn(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Subject: | Re: WIP Patch: Pgbench Serialization and deadlock errors |
Date: | 2017-06-16 10:31:27 |
Message-ID: | bcfec2e7ebd6dc741b85650456068914@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Marina Polyakova | 2017-06-16 10:38:07 | Re: WIP Patch: Pgbench Serialization and deadlock errors |
Previous Message | Amit Kapila | 2017-06-16 10:30:47 | Re: Getting server crash on Windows when using ICU collation |