Re: [PATCH] SQL function to report log message

On Mon, Jul 13, 2015 at 1:11 AM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:

> On Mon, Jul 13, 2015 at 4:54 PM, dinesh kumar <dineshkumar02(at)gmail(dot)com>
> wrote:
> > Would like to discuss on below feature here.
> >
> > Feature:
> > Having an SQL function, to write messages to log destination.
> >
> > Justification:
> > 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.

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

Let me know if i miss anything here.

Best Regards,
Dinesh
manojadinesh.blogspot.com

A log message is here to give information about the
> state of something that happens in backend, but in the case of this
> function the event that happens is the content of the function itself.
> It also adds a new log level for something that has a unique usage,
> which looks like an overkill to me. Btw, you could do something more
> advanced with simply an extension if you really want to play with this
> area... But I am dubious about what kind of applications would use
> that.
> --
> Michael
>