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