On 12-09-2018 17:04, Fabien COELHO wrote:
Hello Marina,
You can get other errors that cannot happen for only one client if you
use shell commands in meta commands:
Or if you use untrusted procedural languages in SQL expressions (see
the used file in the attachments):
Or if you try to create a function and perhaps replace an existing
one:
Sure. Indeed there can be shell errors, perl errors, create functions
conflicts... I do not understand what is your point wrt these.
I'm mostly saying that your patch should focus on implementing the
retry feature when appropriate, and avoid changing the behavior (error
displayed, abort or not) on features unrelated to serialization &
deadlock errors.
Maybe there are inconsistencies, and "bug"/"feature" worth fixing, but
if so that should be a separate patch, if possible, and if these are
bugs they could be backpatched.
For now I'm still convinced that pgbench should keep on aborting on
"\set" or SQL syntax errors, and show clear error messages on these,
and your examples have not changed my mind on that point.
I'm fine with renaming the field if it makes thinks clearer. They are
all counters, so naming them "cnt" or "total_cnt" does not help much.
Maybe "succeeded" or "success" to show what is really counted?
Perhaps renaming of StatsData.cnt is better than just adding a comment
to this field. But IMO we have the same problem (They are all
counters, so naming them "cnt" or "total_cnt" does not help much.) for
CState.cnt which cannot be named in the same way because it also
includes skipped and failed transactions.
Hmmm. CState's cnt seems only used to implement -t anyway? I'm okay if
it has a different name, esp if it has a different semantics.
Ok!
I think
I was arguing only about cnt in StatsData.
The discussion about this has become entangled from the beginning,
because as I wrote in [1] at first I misread your original proposal...
[1]
https://www.postgresql.org/message-id/d318cdee8f96de6b1caf2ce684ffe4db%40postgrespro.ru
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
