Re: replication commands and log_statements - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: replication commands and log_statements
Date
Msg-id 20140812225404.GE16422@tamriel.snowman.net
Whole thread Raw
In response to Re: replication commands and log_statements  (Bruce Momjian <bruce@momjian.us>)
Responses Re: replication commands and log_statements
List pgsql-hackers
* Bruce Momjian (bruce@momjian.us) wrote:
> On Tue, Aug 12, 2014 at 10:07:34AM +0530, Amit Kapila wrote:
> > On Tue, Aug 12, 2014 at 9:29 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> > > On Tue, Aug 12, 2014 at 2:34 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> > > >
> > > > If you have a user devoted to it, I suppose that's true.  I still
> > > > think it shouldn't get munged together like that.
> > >
> > > Why do we need to treat only replication commands as special ones and
> > > add new parameter to display them?
> >
> > 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..  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.  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..
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Minmax indexes
Next
From: Bruce Momjian
Date:
Subject: Re: jsonb format is pessimal for toast compression