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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
