On Wed, Jun 11, 2014 at 7:42 AM, Magnus Hagander <magnus@hagander.net> wrote:
>> Replication commands like IDENTIFY_COMMAND are not logged even when
>> log_statements is set to all. Some users who use log_statements to
>> audit *all* statements might dislike this current situation. So I'm
>> thinking to change log_statements or add something like log_replication
>> so that we can log replication commands. Thought?
>
> +1. I think adding a separate parameter is the way to go.
>
> The other option would be to turn log_statements into a parameter that you
> specify multiple ones
I kind of like this idea, but...
> - so instead of "all" today it would be "ddl,dml,all"
> or something like that, and then you'd also add "replication" as an option.
> But that would cause all sorts of backwards compatibility annoyances.. And
> do you really want to be able to say things like "ddl,all" meanin you'd get
> ddl and select but not dml?
...you lost me here. I mean, I think it could be quite useful to
redefine the existing GUC as a list. We could continue to have ddl,
dml, and all as tokens that would be in the list, but you wouldn't
write "ddl,dml,all" because "all" would include everything that those
other ones would log. But then you could have combinations like
"dml,replication" and so on. And you could do much more fine-grained
things, like allow log_statement=create,alter,drop to log all such
statements but not, for example, cluster.
I think if we go the route of adding a separate GUC for this, we're
going to get tired of adding GUCs way before we've come close to
meeting the actual requirements in this area. A comma-separated list
of tokens seems to offer a lot more flexibility.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company