On Wed, Sep 10, 2014 at 7:39 PM, Fujii Masao wrote:
> Thanks for reviewing the patch!
>
> On Wed, Sep 10, 2014 at 4:57 PM, Heikki Linnakangas
> wrote:
>> On 08/28/2014 11:38 AM, Fujii Masao wrote:
>>>
>>> On Thu, Jun 19, 2014 at 5:29 PM, Ian Barwick wrote:
- minor rewording for the des
Thanks for reviewing the patch!
On Wed, Sep 10, 2014 at 4:57 PM, Heikki Linnakangas
wrote:
> On 08/28/2014 11:38 AM, Fujii Masao wrote:
>>
>> On Thu, Jun 19, 2014 at 5:29 PM, Ian Barwick wrote:
>>>
>>> - minor rewording for the description, mentioning that statements will
>>>still be logged
On 08/28/2014 11:38 AM, Fujii Masao wrote:
On Thu, Jun 19, 2014 at 5:29 PM, Ian Barwick wrote:
- minor rewording for the description, mentioning that statements will
still be logged as DEBUG1 even if parameter set to 'off' (might
prevent reports of the kind "I set it to 'off', why am I st
On Thu, Jun 19, 2014 at 5:29 PM, Ian Barwick wrote:
> On 12/06/14 20:37, Fujii Masao wrote:
>>
>> On Wed, Jun 11, 2014 at 11:55 PM, Tom Lane wrote:
>>>
>>> Andres Freund writes:
Your wish just seems like a separate feature to me. Including
replication commands in 'all' seems corre
On Tue, Aug 26, 2014 at 7:17 AM, Fujii Masao wrote:
> On Wed, Aug 20, 2014 at 1:14 PM, Michael Paquier
> wrote:
>> On Wed, Aug 20, 2014 at 2:06 AM, Robert Haas wrote:
>>>
>>> On Sat, Aug 16, 2014 at 10:27 AM, Amit Kapila
>>> wrote:
>>> > I think ideally it would have been better if we could hav
On Wed, Aug 20, 2014 at 1:14 PM, Michael Paquier
wrote:
>
>
>
> On Wed, Aug 20, 2014 at 2:06 AM, Robert Haas wrote:
>>
>> On Sat, Aug 16, 2014 at 10:27 AM, Amit Kapila
>> wrote:
>> > I think ideally it would have been better if we could have logged
>> > replication commands under separate log_le
On Wed, Aug 20, 2014 at 2:06 AM, Robert Haas wrote:
> On Sat, Aug 16, 2014 at 10:27 AM, Amit Kapila
> wrote:
> > 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
On Sat, Aug 16, 2014 at 10:27 AM, Amit Kapila wrote:
> 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 ahea
On Thu, Aug 14, 2014 at 7:19 PM, Stephen Frost wrote:
> * Amit Kapila (amit.kapil...@gmail.com) wrote:
> > On Thu, Aug 14, 2014 at 5:56 AM, Stephen Frost
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,
Amit,
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> On Thu, Aug 14, 2014 at 5:56 AM, Stephen Frost 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
>
On Thu, Aug 14, 2014 at 5:56 AM, Stephen Frost wrote:
> * Amit Kapila (amit.kapil...@gmail.com) wrote:
> Oh, to be clear- I agree that logging of queries executed through SPI is
> desirable; I'd certainly like to have that capability without having to
> go through the auto-explain module or write
On Thu, Aug 14, 2014 at 10:40 AM, Fujii Masao wrote:
> On Thu, Aug 14, 2014 at 9:26 AM, Stephen Frost wrote:
>> * Amit Kapila (amit.kapil...@gmail.com) wrote:
>>> On Wed, Aug 13, 2014 at 4:24 AM, Stephen Frost wrote:
>>> > Not entirely sure what you're referring to as 'internally generated'
>>>
On Thu, Aug 14, 2014 at 9:26 AM, Stephen Frost wrote:
> * Amit Kapila (amit.kapil...@gmail.com) wrote:
>> On Wed, Aug 13, 2014 at 4:24 AM, Stephen Frost wrote:
>> > Not entirely sure what you're referring to as 'internally generated'
>> > here..
>>
>> Here 'internally generated' means that user d
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> On Wed, Aug 13, 2014 at 4:24 AM, Stephen Frost wrote:
> > 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/bac
On Wed, Aug 13, 2014 at 4:24 AM, Stephen Frost 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 gen
* Bruce Momjian (br...@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 wrote:
> > > On Tue, Aug 12, 2014 at 2:34 AM, Robert Haas
> > > wrote:
> > > >
> > > > If you have a user devoted to it, I suppose that's true
On Tue, Aug 12, 2014 at 10:07:34AM +0530, Amit Kapila wrote:
> On Tue, Aug 12, 2014 at 9:29 AM, Fujii Masao wrote:
> > On Tue, Aug 12, 2014 at 2:34 AM, Robert Haas wrote:
> > >
> > > If you have a user devoted to it, I suppose that's true. I still
> > > think it shouldn't get munged together lik
On Tue, Aug 12, 2014 at 9:29 AM, Fujii Masao wrote:
> On Tue, Aug 12, 2014 at 2:34 AM, Robert Haas
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 specia
On Tue, Aug 12, 2014 at 2:34 AM, Robert Haas wrote:
> On Fri, Aug 8, 2014 at 1:04 PM, Fujii Masao wrote:
>> On Sat, Aug 9, 2014 at 12:29 AM, Robert Haas wrote:
>>> On Fri, Aug 8, 2014 at 11:00 AM, Bruce Momjian wrote:
On Fri, Aug 8, 2014 at 08:51:13AM -0400, Robert Haas wrote:
> On Th
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Aug 8, 2014 at 1:04 PM, Fujii Masao wrote:
> > You can do that by executing
> > "ALTER ROLE SET log_statement TO 'all'".
> > If you don't use the replication user to execute SQL statements,
> > no SQL statements are logged in that setting.
>
On Fri, Aug 8, 2014 at 1:04 PM, Fujii Masao wrote:
> On Sat, Aug 9, 2014 at 12:29 AM, Robert Haas wrote:
>> On Fri, Aug 8, 2014 at 11:00 AM, Bruce Momjian wrote:
>>> On Fri, Aug 8, 2014 at 08:51:13AM -0400, Robert Haas wrote:
On Thu, Aug 7, 2014 at 12:07 PM, Abhijit Menon-Sen
wrote:
On Sat, Aug 9, 2014 at 12:29 AM, Robert Haas wrote:
> On Fri, Aug 8, 2014 at 11:00 AM, Bruce Momjian wrote:
>> On Fri, Aug 8, 2014 at 08:51:13AM -0400, Robert Haas wrote:
>>> On Thu, Aug 7, 2014 at 12:07 PM, Abhijit Menon-Sen
>>> wrote:
>>> > At 2014-08-07 23:22:43 +0900, masao.fu...@gmail.com
On Fri, Aug 8, 2014 at 11:00 AM, Bruce Momjian wrote:
> On Fri, Aug 8, 2014 at 08:51:13AM -0400, Robert Haas wrote:
>> On Thu, Aug 7, 2014 at 12:07 PM, Abhijit Menon-Sen
>> wrote:
>> > At 2014-08-07 23:22:43 +0900, masao.fu...@gmail.com wrote:
>> >> That is, we log replication commands only whe
On Fri, Aug 8, 2014 at 08:51:13AM -0400, Robert Haas wrote:
> On Thu, Aug 7, 2014 at 12:07 PM, Abhijit Menon-Sen
> wrote:
> > At 2014-08-07 23:22:43 +0900, masao.fu...@gmail.com wrote:
> >> That is, we log replication commands only when log_statement is set to
> >> all. Neither new parameter is
On Thu, Aug 7, 2014 at 12:07 PM, Abhijit Menon-Sen wrote:
> At 2014-08-07 23:22:43 +0900, masao.fu...@gmail.com wrote:
>> That is, we log replication commands only when log_statement is set to
>> all. Neither new parameter is introduced nor log_statement is
>> redefined as a list.
>
> That sounds
At 2014-08-07 23:22:43 +0900, masao.fu...@gmail.com wrote:
>
> That is, we log replication commands only when log_statement is set to
> all. Neither new parameter is introduced nor log_statement is
> redefined as a list.
That sounds good to me.
-- Abhijit
--
Sent via pgsql-hackers mailing list
On Wed, Jul 2, 2014 at 4:26 AM, Abhijit Menon-Sen wrote:
> Hi.
>
> Do we have any consensus about what to do with these two patches?
>
> 1. Introduce a "log_replication_command" setting.
> 2. Change log_statement to be a list of tokens.
>
> If I understand correctly, there weren't any strong objec
Hi.
Do we have any consensus about what to do with these two patches?
1. Introduce a "log_replication_command" setting.
2. Change log_statement to be a list of tokens.
If I understand correctly, there weren't any strong objections to the
former, but the situation is less clear when it comes to t
On Mon, Jun 23, 2014 at 11:15 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Similarly,
>> building a logging facility that meets the needs of real users is
>> going to require a configuration method more flexible than a total
>> order with four choices. I happen to th
* Robert Haas (robertmh...@gmail.com) wrote:
> Similarly,
> building a logging facility that meets the needs of real users is
> going to require a configuration method more flexible than a total
> order with four choices. I happen to think a list of comma-separated
> tokens is a pretty good choice
On Fri, Jun 20, 2014 at 9:48 AM, Tom Lane wrote:
> Fujii Masao writes:
>> OK, I've just implemented the patch (attached) which does this, i.e.,
>> redefines
>> log_statement as a list. Thanks to the patch, log_statement can be set
>> to "none",
>> "ddl", "mod", "dml", "all", and any combinations
On Fri, Jun 20, 2014 at 10:48 PM, Tom Lane wrote:
> Fujii Masao writes:
>> OK, I've just implemented the patch (attached) which does this, i.e.,
>> redefines
>> log_statement as a list. Thanks to the patch, log_statement can be set
>> to "none",
>> "ddl", "mod", "dml", "all", and any combination
Fujii Masao writes:
> OK, I've just implemented the patch (attached) which does this, i.e.,
> redefines
> log_statement as a list. Thanks to the patch, log_statement can be set
> to "none",
> "ddl", "mod", "dml", "all", and any combinations of them. The meanings of
> "none", "ddl", "mod" and "all
On Thu, Jun 12, 2014 at 10:55 PM, Robert Haas wrote:
> On Wed, Jun 11, 2014 at 7:42 AM, Magnus Hagander 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 th
On 12/06/14 20:37, Fujii Masao wrote:
On Wed, Jun 11, 2014 at 11:55 PM, Tom Lane wrote:
Andres Freund writes:
Your wish just seems like a separate feature to me. Including
replication commands in 'all' seems correct independent of the desire
for a more granular control.
No, I think I've got
On Wed, Jun 11, 2014 at 7:42 AM, Magnus Hagander 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_stat
On Wed, Jun 11, 2014 at 11:55 PM, Tom Lane wrote:
> Andres Freund writes:
>> Your wish just seems like a separate feature to me. Including
>> replication commands in 'all' seems correct independent of the desire
>> for a more granular control.
>
> No, I think I've got to vote with the other side
Andres Freund writes:
> Your wish just seems like a separate feature to me. Including
> replication commands in 'all' seems correct independent of the desire
> for a more granular control.
No, I think I've got to vote with the other side on that.
The reason we can have log_statement as a scalar
On 2014-06-11 14:50:34 +0200, Magnus Hagander wrote:
> On Wed, Jun 11, 2014 at 2:35 PM, Andres Freund
> wrote:
>
> > On 2014-06-11 14:22:43 +0200, Magnus Hagander wrote:
> > > Yes, but how would you specify for example "i want DDL and all
> > replication
> > > commands" (which is quite a reasonab
On Wed, Jun 11, 2014 at 2:35 PM, Andres Freund
wrote:
> On 2014-06-11 14:22:43 +0200, Magnus Hagander wrote:
> > Yes, but how would you specify for example "i want DDL and all
> replication
> > commands" (which is quite a reasonable thing to log, I believe). If you
> > actually require it to be s
On 2014-06-11 14:22:43 +0200, Magnus Hagander wrote:
> Yes, but how would you specify for example "i want DDL and all replication
> commands" (which is quite a reasonable thing to log, I believe). If you
> actually require it to be set to "all", most people won't have any use at
> all for it...
Th
On Wed, Jun 11, 2014 at 2:17 PM, Andres Freund
wrote:
> On 2014-06-11 13:42:58 +0200, Magnus Hagander wrote:
> > On Wed, Jun 11, 2014 at 12:34 PM, Fujii Masao
> wrote:
> >
> > > Hi,
> > >
> > > Replication commands like IDENTIFY_COMMAND are not logged even when
> > > log_statements is set to all
On 2014-06-11 13:42:58 +0200, Magnus Hagander wrote:
> On Wed, Jun 11, 2014 at 12:34 PM, Fujii Masao wrote:
>
> > Hi,
> >
> > 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
On Wed, Jun 11, 2014 at 12:34 PM, Fujii Masao wrote:
> Hi,
>
> 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_st
On 2014-06-11 19:34:25 +0900, Fujii Masao wrote:
> Hi,
>
> 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_stateme
Hi,
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
46 matches
Mail list logo
