On 7/13/15 12:39 PM, dinesh kumar wrote:
> 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.
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).
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. I see the similar item in our development list <http://www.postgresql.org/message-id/53a8e96e.9060...@2ndquadrant.com>.
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.
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
