Re: extend pgbench expressions with functions

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: extend pgbench expressions with functions
Date: 2016-01-28 06:36:24
Message-ID: alpine.DEB.2.10.1601280721580.26012@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2016-01-28 06:48:43 Re: Optimization for updating foreign tables in Postgres FDW
Previous Message Rushabh Lathia 2016-01-28 06:20:31 Re: Optimization for updating foreign tables in Postgres FDW