On Wed, Aug 13, 2014 at 4:24 AM, Stephen Frost <sfr...@snowman.net> wrote: > * Bruce Momjian (br...@momjian.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-8rdgnwidscqvtps1...@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
