> As of now, we don't have an SQL function to write custom/application > messages to log destination. We have "RAISE" clause which is controlled by > log_ parameters. If we have an SQL function which works irrespective of log > settings, that would be a good for many log parsers. What i mean is, in DBA > point of view, if we route all our native OS stats to log files in a proper > format, then we can have our log reporting tools to give most effective > reports. Also, Applications can log their own messages to postgres log > files, which can be monitored by DBAs too.
What's the actual use case for this feature other than it would be good to have it?
That's a good question Michael.
When i was working as a DBA for a different RDBMS, developers used to write some serious APP errors, Followed by instructions into some sort of log and trace files. Since, DBAs didn't have the permission to check app logs, which was owned by Ops team.
In my old case, application was having serious OOM issues, which was crashing frequently after the deployment. It wasn't the consistent behavior from the app side, hence they used to sent a copy all APP metrics to trace files, and we were monitoring the DB what was happening during the spike on app servers.
Spewing a bunch of stuff into the postgres log doesn't seem like an improvement here.
Agreed Jim.
I don't really see the point of what you're describing here. Just do something like RAISE WARNING which should normally be high enough to make it into the logs. Or use a pl language that will let you write your own logfile on the server (ie: plperlu).
True. Using plperlu, shall we bypass our log_* settings. If it's true, i wasn't sure about it.
I didn't mean that, we need to have this feature, since we have it on other RDBMS. I don't see a reason, why don't we have this in our PG too.
That's not at all what that item is talking about. It's talking about exposing ereport as a SQL function, without altering the rest of our logging behavior.
Ah. It's' my bad interpretation. Let me work on it, and will send a new patch as a wrapper sql function for ereport.