Pgbench is a bench tool, not a production tool.
I don't really see how that's relevant.
My point is that I do not see any added value for pgbench to keep on
executing a performance bench if some clients die due to script errors: it
is more useful to stop the whole bench and report the issue, so the user
can fix their script, than to keep going on with the remaining clients,
from a benchmarking perspective.
So I'm arguing that exiting, with an error message, is better than
handling user errors.
When I run a program and it dies after causing the operating system to
send it a fatal signal, I say to myself "self, that program has a bug".
Other people may have different reactions, but that's mine.
I was talking about an exit call generated on a float to int conversion
error when there is an error in the user script. The bug is in the user
script and this is clearly reported by pgbench.
However, your argument may be relevant for avoiding fatal signal such as
generated by INT64_MAX / -1, because on this one the message error is
terse so how to fix the issue is not clear to the user.
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: