Tom Lane wrote:
> Bruce Momjian writes:
> > Simon Riggs wrote:
> >> I'm particularly concerned that people make such changes too quickly.
> >> There are many things in this area of code that need changing, but also
> >> many more that do not. If we are to move forwards we need to avoid going
> >>
Bruce Momjian writes:
> Simon Riggs wrote:
>> I'm particularly concerned that people make such changes too quickly.
>> There are many things in this area of code that need changing, but also
>> many more that do not. If we are to move forwards we need to avoid going
>> one step forwards, one step
Simon Riggs wrote:
> On Tue, 2011-01-18 at 10:57 -0500, Tom Lane wrote:
> > Magnus Hagander writes:
> > > Is there *any* usecase for setting them differently though?
> >
> > I can't believe we're still engaged in painting this bikeshed. Let's
> > just control it off log_connections and have done
On Tue, 2011-01-18 at 10:57 -0500, Tom Lane wrote:
> Magnus Hagander writes:
> > Is there *any* usecase for setting them differently though?
>
> I can't believe we're still engaged in painting this bikeshed. Let's
> just control it off log_connections and have done.
Yes, this is a waste of time
All,
Just speaking as someone who does a lot of log-crunching for performance
review, I don't find having a separate log_connections option for
replication terribly useful. It's easy enough for me to just log all
connections and filter for the type of connections I want.
Even in cases where ther
On Tue, Jan 18, 2011 at 17:33, Robert Haas wrote:
> On Tue, Jan 18, 2011 at 2:15 AM, Heikki Linnakangas
> wrote:
>> I also find it weird that incoming replication connections are logged by
>> default. In the standby, we also log "streaming replication successfully
>> connected to primary", which
On Tue, Jan 18, 2011 at 2:15 AM, Heikki Linnakangas
wrote:
> I also find it weird that incoming replication connections are logged by
> default. In the standby, we also log "streaming replication successfully
> connected to primary", which serves much of the same debugging purpose.
Oh, good point
Magnus Hagander writes:
> Is there *any* usecase for setting them differently though?
I can't believe we're still engaged in painting this bikeshed. Let's
just control it off log_connections and have done.
BTW, what about log_disconnections --- does a walsender emit a message
according to that?
On Tue, Jan 18, 2011 at 10:56, Fujii Masao wrote:
> On Tue, Jan 18, 2011 at 5:17 PM, Magnus Hagander wrote:
>>> We should treat log_disconnections the same?
>>
>> We could keep it a boolean, but then only log disconnections for the
>> cases that are mentioned in log_connections?
>>
>> It doesn't
On Tue, Jan 18, 2011 at 5:17 PM, Magnus Hagander wrote:
>> We should treat log_disconnections the same?
>
> We could keep it a boolean, but then only log disconnections for the
> cases that are mentioned in log_connections?
>
> It doesn't make sense to log disconnection for a connection we didn't
On Tue, Jan 18, 2011 at 08:21, Fujii Masao wrote:
> On Tue, Jan 18, 2011 at 4:15 PM, Heikki Linnakangas
> wrote:
>> I also find it weird that incoming replication connections are logged by
>> default. In the standby, we also log "streaming replication successfully
>> connected to primary", which
On Tue, Jan 18, 2011 at 4:15 PM, Heikki Linnakangas
wrote:
> I also find it weird that incoming replication connections are logged by
> default. In the standby, we also log "streaming replication successfully
> connected to primary", which serves much of the same debugging purpose. That
> standby-
On 17.01.2011 21:04, Robert Haas wrote:
On Mon, Jan 17, 2011 at 1:57 PM, Tom Lane wrote:
I'm of the opinion that the correct way of "lowering in later releases"
is to make the messages obey Log_connections. The "needed for debug"
argument seems mighty weak to me even for the time, and surely f
On Mon, Jan 17, 2011 at 1:57 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Jan 17, 2011 at 17:46, Tom Lane wrote:
>>> I think it'd make more sense just to say that replication connections
>>> are subject to the same log_connections rule as others. An extra GUC
>>> for this is surely
Magnus Hagander writes:
> On Mon, Jan 17, 2011 at 17:46, Tom Lane wrote:
>> I think it'd make more sense just to say that replication connections
>> are subject to the same log_connections rule as others. An extra GUC
>> for this is surely overkill.
> I thought so, but Robert didn't agree. And
On Mon, Jan 17, 2011 at 17:46, Tom Lane wrote:
> Magnus Hagander writes:
>> Before I go ahead and commit the part that adds
>> log_replication_connections, anybody else want to object to the idea?
>
> I think it'd make more sense just to say that replication connections
> are subject to the same
Magnus Hagander writes:
> Before I go ahead and commit the part that adds
> log_replication_connections, anybody else want to object to the idea?
I think it'd make more sense just to say that replication connections
are subject to the same log_connections rule as others. An extra GUC
for this is
On Mon, Jan 17, 2011 at 16:31, Robert Haas wrote:
> On Mon, Jan 17, 2011 at 10:12 AM, Magnus Hagander wrote:
>> On Mon, Jan 17, 2011 at 16:03, Robert Haas wrote:
>>> On Mon, Jan 17, 2011 at 8:58 AM, Magnus Hagander
>>> wrote:
>>> What do you have in mind?
>>
>> Either having it con
On Mon, Jan 17, 2011 at 10:12 AM, Magnus Hagander wrote:
> On Mon, Jan 17, 2011 at 16:03, Robert Haas wrote:
>> On Mon, Jan 17, 2011 at 8:58 AM, Magnus Hagander wrote:
>> What do you have in mind?
>
> Either having it controlled by log_connections, or perhaps have a
> log_highpri
On Mon, Jan 17, 2011 at 16:03, Robert Haas wrote:
> On Mon, Jan 17, 2011 at 8:58 AM, Magnus Hagander wrote:
> What do you have in mind?
Either having it controlled by log_connections, or perhaps have a
log_highpriv_connections that controls replication *and* superuser, to
On Mon, Jan 17, 2011 at 8:58 AM, Magnus Hagander wrote:
What do you have in mind?
>>>
>>> Either having it controlled by log_connections, or perhaps have a
>>> log_highpriv_connections that controls replication *and* superuser, to
>>> be somewhat consistent.
>>
>> -1. We could provide an opt
On Mon, Jan 17, 2011 at 14:00, Robert Haas wrote:
> On Mon, Jan 17, 2011 at 1:53 AM, Magnus Hagander wrote:
>> On Mon, Jan 17, 2011 at 03:06, Robert Haas wrote:
>>> On Sun, Jan 16, 2011 at 9:19 AM, Magnus Hagander
>>> wrote:
Currently, replication connections *always* logs something like:
On Mon, Jan 17, 2011 at 1:53 AM, Magnus Hagander wrote:
> On Mon, Jan 17, 2011 at 03:06, Robert Haas wrote:
>> On Sun, Jan 16, 2011 at 9:19 AM, Magnus Hagander wrote:
>>> Currently, replication connections *always* logs something like:
>>> LOG: replication connection authorized: user=mha host=[
On Mon, Jan 17, 2011 at 03:06, Robert Haas wrote:
> On Sun, Jan 16, 2011 at 9:19 AM, Magnus Hagander wrote:
>> Currently, replication connections *always* logs something like:
>> LOG: replication connection authorized: user=mha host=[local]
>>
>> There's no way to turn that off.
>>
>> I can't fi
On Sun, Jan 16, 2011 at 9:19 AM, Magnus Hagander wrote:
> Currently, replication connections *always* logs something like:
> LOG: replication connection authorized: user=mha host=[local]
>
> There's no way to turn that off.
>
> I can't find the reasoning behind this - why is this one not
> contro
Currently, replication connections *always* logs something like:
LOG: replication connection authorized: user=mha host=[local]
There's no way to turn that off.
I can't find the reasoning behind this - why is this one not
controlled by log_connections like normal ones? There's a comment in
the co
26 matches
Mail list logo
