Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors

> Hi,

Hello!

> I think that's a good idea and sorely needed.

Thanks, I'm very glad to hear it!

>> - if there were these failures during script execution this 
>> "transaction" is
>> marked
>> appropriately in logs;
>> - numbers of "transactions" with these failures are printed in 
>> progress, in
>> aggregation logs and in the end with other results (all and for each
>> script);
> 
> I guess that'll include a "rolled-back %' or 'retried %' somewhere?

Not exactly, see documentation:

+   If transaction has serialization / deadlock failure or them both 
(last thing
+   is possible if used script contains several transactions; see
+   <xref linkend="transactions-and-scripts"
+   endterm="transactions-and-scripts-title"> for more information), its
+   <replaceable>time</> will be reported as <literal>serialization 
failure</> /
+   <literal>deadlock failure</> /
+   <literal>serialization and deadlock failures</> appropriately.

+   Example with serialization, deadlock and both these failures:
+<screen>
+1 128 24968 0 1496759158 426984
+0 129 serialization failure 0 1496759158 427023
+3 129 serialization failure 0 1496759158 432662
+2 128 serialization failure 0 1496759158 432765
+0 130 deadlock failure 0 1496759159 460070
+1 129 serialization failure 0 1496759160 485188
+2 129 serialization and deadlock failures 0 1496759160 485339
+4 130 serialization failure 0 1496759160 485465
+</screen>

I have understood proposals in next messages of this thread that the 
most interesting case is to retry failed transaction. Do you think it's 
better to write for example "rolled-back after % retries (serialization 
failure)' or "time (retried % times, serialization and deadlock 
failures)'?

>> Advanced options:
>> - mostly for testing built-in scripts: you can set the default 
>> transaction
>> isolation level by the appropriate benchmarking option (-I);
> 
> I'm less convinced of the need of htat, you can already set arbitrary
> connection options with
> PGOPTIONS='-c default_transaction_isolation=serializable' pgbench

Oh, thanks, I forgot about it =[

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

Álvaro Herrera later in 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.

With his explanation has my text become clearer?

-- 
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company