Re: replication commands and log_statements

On Thu, Aug 14, 2014 at 5:56 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Amit Kapila (amit(dot)kapila16(at)gmail(dot)com) wrote:
> Oh, to be clear- I agree that logging of queries executed through SPI is
> desirable; I'd certainly like to have that capability without having to
> go through the auto-explain module or write my own module. That doesn't
> mean we should consider them either "internal" (which I don't really
> agree with- consider anonymous DO blocks...) or somehow related to
> replication logging.
>
> > >Could we enable logging of both with a single GUC?
> > >
> > > I don't see those as the same at all. I'd like to see improved
> > > flexibility in this area, certainly, but don't want two independent
> > > considerations like these tied to one GUC..
> >
> > Agreed, I also think both are different and shouldn't be logged
> > with one GUC. Here the important thing to decide is which is
> > the better way to proceed for allowing logging of replication
> > commands such that it can allow us to extend it for more
> > things. We have discussed below options:
> >
> > a. Make log_statement a list of comma separated options
> > b. Have a separate parameter something like log_replication*
> > c. Log it when user has mentioned option 'all' in log_statement.
>
> Regarding this, I'm generally in the camp that says to just include it
> in 'all' and be done with it- for now.

Okay, but tomorrow if someone wants to implement a patch to log
statements executed through SPI (statements inside functions), then
what will be your suggestion, does those also can be allowed to log
with 'all' option or you would like to suggest him to wait for a proper
auditing system?

Wouldn't allowing to log everything under 'all' option can start
confusing some users without having individual
(ddl, mod, replication, ...) options for different kind of statements.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com