Re: replication commands and log_statements

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>
Subject: Re: replication commands and log_statements
Date: 2014-08-16 14:27:57
Message-ID: CAA4eK1Jmu6wOR4G0whR=+vB5WfDThDYuY8eauU2e_N9h05Qesw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 14, 2014 at 7:19 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Amit Kapila (amit(dot)kapila16(at)gmail(dot)com) wrote:
> > On Thu, Aug 14, 2014 at 5:56 AM, Stephen Frost <sfrost(at)snowman(dot)net>
wrote:
> > > 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?
>
> No, I'd suggest having a different option for it as that would be a huge
> change for people who are already doing 'all', potentially.

Not only that, I think another important reason is that those represent
separate set of functionality and some users could be interested to
log those statements alone or along with other set of commands.

> Adding the
> replication commands is extremely unlikely to cause individuals who are
> already logging 'all' any problems, as far as I can tell.

As 'all' is superset for all commands, so anyway it would have been
logged under 'all', the point is that whether replication commands
can be considered to have a separate log level parameter. To me, it
appears that it deserves a separate log level parameter even though
today number of commands which fall under this category are less,
however it can increase tomorrow. Also if tomorrow there is a consensus
on how to extend log_statement parameter, it is quite likely that
someone will come up with a patch to consider replication commands
as separate log level.

I think ideally it would have been better if we could have logged
replication commands under separate log_level, but as still there
is no consensus on extending log_statement and nobody is even
willing to pursue, it seems okay to go ahead and log these under
'all' level.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-08-16 18:00:48 Re: 9.5: Better memory accounting, towards memory-bounded HashAgg
Previous Message Tomas Vondra 2014-08-16 14:00:50 Re: 9.5: Better memory accounting, towards memory-bounded HashAgg