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
