Re: [PATCH] SQL function to report log message

On Mon, Jul 13, 2015 at 1:29 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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.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.
>

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
>