Hello Robert,

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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to