Re: [PATCH] SQL function to report log message

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.9060507@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