On 11/3/21 09:09, Robert Haas wrote:
> For better or for worse, the
> distinction between ERROR, FATAL, and PANIC is entirely based on what
> we do after printing the message, and NOT on how serious the message
> is.
THAT is a real problem with our error handling and logging system. Often
using RAISE in a user defined function or procedure is part of the
communication between the application's code in the backend and the
parts in the middleware. The information that a function rejected user
input after a sanity check doesn't belong in the system log. It should
produce an error message on the user's end and that is it. However,
currently there is no way for a UDF to ensure the transaction gets
rolled back without raising an ERROR and bloating the log.
For example the BenchmarkSQL UDF implementation raises such ERROR for
the transactions that the TPC-C requires to contain an input error
(non-existing ITEM), which happens on 1% of all NEW-ORDER transactions.
Running an 8-core system with plenty of RAM close to saturation will
generate about 10MB of log just for that per hour. That is a quarter GB
of useless garbage, no DBA is ever going to be interested in, every day.
If anybody is worried about producing too much log output, this should
be their primary focus.
Regards, Jan