Re: replication commands and log_statements

* Amit Kapila (amit(dot)kapila16(at)gmail(dot)com) wrote:
> On Wed, Aug 13, 2014 at 4:24 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > Not entirely sure what you're referring to as 'internally generated'
> > here..
>
> Here 'internally generated' means that user doesn't execute those
> statements, rather the replication/backup code form these statements
> (IDENTIFY_SYSTEM, TIMELINE_HISTORY, BASE_BACKUP, ...)
> and send to server to get the appropriate results.

You could argue the same about pg_dump.. I'd not thought of it before,
but it might be kind of neat to have psql support "connect in
replication mode" and then allow the user to run replication commands.
Still, this isn't the same.

> Yes, few days back I have seen one of the user expects
> such functionality. Refer below mail:
> http://www.postgresql.org/message-id/CAA4eK1LVuirQnMjV1vTMrG_F+1F9e9-8RDGnwiDsCqVTps1ptQ@mail.gmail.com

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. This is just another example
of where we really need a much more granular and configurable framework
for auditing and we're not going to get through GUCs, so let's keep the
GUC based approach simple and familiar to our users and build a proper
auditing system.

Thanks,

Stephen