Re: extend pgbench expressions with functions - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: extend pgbench expressions with functions
Date
Msg-id alpine.DEB.2.10.1601280721580.26012@sto
Whole thread Raw
In response to Re: extend pgbench expressions with functions  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: extend pgbench expressions with functions  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Rushabh Lathia
Date:
Subject: Re: Optimization for updating foreign tables in Postgres FDW
Next
From: Etsuro Fujita
Date:
Subject: Re: Optimization for updating foreign tables in Postgres FDW