On Mon, Jul 13, 2015 at 1:29 PM, Jim Nasby <jim.na...@bluetreble.com> wrote:
> 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. > > 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. >> >> 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. > Ah. It's' my bad interpretation. Let me work on it, and will send a new patch as a wrapper sql function for ereport. Thanks again. Regards, Dinesh manojadinesh.blogspot.com -- > Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX > Data in Trouble? Get it in Treble! http://BlueTreble.com >
