From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | dinesh kumar <dineshkumar02(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] SQL function to report log message |
Date: | 2015-07-13 20:29:43 |
Message-ID: | 55A41FB7.2050103@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-07-13 20:36:21 | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Previous Message | David Christensen | 2015-07-13 20:26:04 | [DESIGN] Incremental checksums |