Re: replication commands and log_statements

On Wed, Aug 13, 2014 at 4:24 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> > On Tue, Aug 12, 2014 at 10:07:34AM +0530, Amit Kapila wrote:

> > > One difference is that replication commands are internally generated
> > > commands. Do we anywhere else log such internally generated
> > > commands with log_statement = all?
>
> 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.

>While they can come from another backend, they don't have to.

> > Good point --- we do not. In fact, this is similar to how we don't log
> > SPI queries, e.g. SQL queries inside functions. We might want to enable
> > that someday too.

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

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

From future extensibility pov, I think option (a) is a good
choice or we could even invent a new scheme for logging
commands which would be something similar to
log_min_messages where we can define levels
level - 0 (none)
level - 1 (dml)
level - 2 (ddl)
level - 4 (replication)
level - 8 (all)

Here if user specifies level = 2, then DDL commands will
get logged and level = 3 would mean log dml and ddl commands.
From backward compatibility, we can keep current parameter
as it is and introduce this a new parameter.

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