Replication logging
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 code that says this is intentional, but I can't figure out why...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Sun, Jan 16, 2011 at 9:19 AM, Magnus Hagander <magnus@hagander.net> 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
controlled by log_connections like normal ones? There's a comment in
the code that says this is intentional, but I can't figure out why...
Because it's reasonably likely that you'd want to log replication
connections but not regular ones? On the theory that replication is
more important than an ordinary login?
What do you have in mind?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Mon, Jan 17, 2011 at 03:06, Robert Haas <robertmhaas@gmail.com> wrote:
On Sun, Jan 16, 2011 at 9:19 AM, Magnus Hagander <magnus@hagander.net> 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
controlled by log_connections like normal ones? There's a comment in
the code that says this is intentional, but I can't figure out why...Because it's reasonably likely that you'd want to log replication
connections but not regular ones? On the theory that replication is
more important than an ordinary login?
Well, a superuser connection is even worse, but we don't hard-code
logging of those.
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.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Mon, Jan 17, 2011 at 1:53 AM, Magnus Hagander <magnus@hagander.net> wrote:
On Mon, Jan 17, 2011 at 03:06, Robert Haas <robertmhaas@gmail.com> wrote:
On Sun, Jan 16, 2011 at 9:19 AM, Magnus Hagander <magnus@hagander.net> 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
controlled by log_connections like normal ones? There's a comment in
the code that says this is intentional, but I can't figure out why...Because it's reasonably likely that you'd want to log replication
connections but not regular ones? On the theory that replication is
more important than an ordinary login?Well, a superuser connection is even worse, but we don't hard-code
logging of those.
From a security perspective, perhaps; but not from an "oh crap my
replication slave can't connect I'm hosed if the server crashes"
perspective.
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 option to turn this on and off, but I
wouldn't want it merged with log_connections or logging of superuser
connections.
Incidentally, I think ClientAuthentication_hook is sufficiently
powerful to allow logging of superuser connections but no others, if
someone wanted to write a contrib module. That doesn't necessarily
mean an in-core facility wouldn't be useful too, but it's at least
worth thinking about using the hook.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Mon, Jan 17, 2011 at 14:00, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Jan 17, 2011 at 1:53 AM, Magnus Hagander <magnus@hagander.net> wrote:
On Mon, Jan 17, 2011 at 03:06, Robert Haas <robertmhaas@gmail.com> wrote:
On Sun, Jan 16, 2011 at 9:19 AM, Magnus Hagander <magnus@hagander.net> 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
controlled by log_connections like normal ones? There's a comment in
the code that says this is intentional, but I can't figure out why...Because it's reasonably likely that you'd want to log replication
connections but not regular ones? On the theory that replication is
more important than an ordinary login?Well, a superuser connection is even worse, but we don't hard-code
logging of those.From a security perspective, perhaps; but not from an "oh crap my
replication slave can't connect I'm hosed if the server crashes"
perspective.
True, there are more than one ways to look at them.
That doesn't mean one is more important than the other though, so they
should be equally configurable, imho.
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 option to turn this on and off, but I
wouldn't want it merged with log_connections or logging of superuser
connections.
Fair enough, we could have a log_replication_connections as a separate
one then? Or having one log_connections, one
log_replication_connections and one log_superuser_connections?
Incidentally, I think ClientAuthentication_hook is sufficiently
powerful to allow logging of superuser connections but no others, if
someone wanted to write a contrib module. That doesn't necessarily
mean an in-core facility wouldn't be useful too, but it's at least
worth thinking about using the hook.
Do we have an example of this hook somewhere already? If not, it could
be made into a useful example of that, perhaps?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Mon, Jan 17, 2011 at 8:58 AM, Magnus Hagander <magnus@hagander.net> 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 option to turn this on and off, but I
wouldn't want it merged with log_connections or logging of superuser
connections.Fair enough, we could have a log_replication_connections as a separate
one then? Or having one log_connections, one
log_replication_connections and one log_superuser_connections?
log_replication_connections seems reasonable. Not sure about
log_superuser_connections.
Incidentally, I think ClientAuthentication_hook is sufficiently
powerful to allow logging of superuser connections but no others, if
someone wanted to write a contrib module. That doesn't necessarily
mean an in-core facility wouldn't be useful too, but it's at least
worth thinking about using the hook.Do we have an example of this hook somewhere already? If not, it could
be made into a useful example of that, perhaps?
contrib/auth_delay
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Mon, Jan 17, 2011 at 16:03, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Jan 17, 2011 at 8:58 AM, Magnus Hagander <magnus@hagander.net> 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 option to turn this on and off, but I
wouldn't want it merged with log_connections or logging of superuser
connections.Fair enough, we could have a log_replication_connections as a separate
one then? Or having one log_connections, one
log_replication_connections and one log_superuser_connections?log_replication_connections seems reasonable. Not sure about
log_superuser_connections.
So basically like this (see attachment).
Incidentally, I think ClientAuthentication_hook is sufficiently
powerful to allow logging of superuser connections but no others, if
someone wanted to write a contrib module. That doesn't necessarily
mean an in-core facility wouldn't be useful too, but it's at least
worth thinking about using the hook.Do we have an example of this hook somewhere already? If not, it could
be made into a useful example of that, perhaps?contrib/auth_delay
Hmm, ok, so not that then :-)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Attachments:
log_replication_connections.patchtext/x-patch; charset=US-ASCII; name=log_replication_connections.patchDownload+43-13
On Mon, Jan 17, 2011 at 10:12 AM, Magnus Hagander <magnus@hagander.net> wrote:
On Mon, Jan 17, 2011 at 16:03, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Jan 17, 2011 at 8:58 AM, Magnus Hagander <magnus@hagander.net> 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 option to turn this on and off, but I
wouldn't want it merged with log_connections or logging of superuser
connections.Fair enough, we could have a log_replication_connections as a separate
one then? Or having one log_connections, one
log_replication_connections and one log_superuser_connections?log_replication_connections seems reasonable. Not sure about
log_superuser_connections.So basically like this (see attachment).
Yeah. Although maybe we should take this opportunity to eliminate the
funky capitalization of Log_connections.
Do we have an example of this hook somewhere already? If not, it could
be made into a useful example of that, perhaps?contrib/auth_delay
Hmm, ok, so not that then :-)
Doesn't preclude this.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Mon, Jan 17, 2011 at 16:31, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Jan 17, 2011 at 10:12 AM, Magnus Hagander <magnus@hagander.net> wrote:
On Mon, Jan 17, 2011 at 16:03, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Jan 17, 2011 at 8:58 AM, Magnus Hagander <magnus@hagander.net> 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 option to turn this on and off, but I
wouldn't want it merged with log_connections or logging of superuser
connections.Fair enough, we could have a log_replication_connections as a separate
one then? Or having one log_connections, one
log_replication_connections and one log_superuser_connections?log_replication_connections seems reasonable. Not sure about
log_superuser_connections.So basically like this (see attachment).
Yeah. Although maybe we should take this opportunity to eliminate the
funky capitalization of Log_connections.
We have that on several other variables as well, I'd rather see that
as a separate thing to change. But is it worth it, wrt it breaking
back-patchability?
Before I go ahead and commit the part that adds
log_replication_connections, anybody else want to object to the idea?
;)
Do we have an example of this hook somewhere already? If not, it could
be made into a useful example of that, perhaps?contrib/auth_delay
Hmm, ok, so not that then :-)
Doesn't preclude this.
Nope, but also doesn't make it the second reason to do it :-) I don't
personally have the itch to go write it, but if somebody does I can
always volunteer to review it...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> 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 surely overkill.
regards, tom lane
On Mon, Jan 17, 2011 at 17:46, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> 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 surely overkill.
I thought so, but Robert didn't agree. And given that things are the
way they are, clearly somebody else didn't agree as well - though I've
been unable to locate the original discussion if there was one.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
On Mon, Jan 17, 2011 at 17:46, Tom Lane <tgl@sss.pgh.pa.us> 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 given that things are the
way they are, clearly somebody else didn't agree as well - though I've
been unable to locate the original discussion if there was one.
The existing behavior dates from here:
http://archives.postgresql.org/pgsql-committers/2010-03/msg00245.php
As best I can tell there was no preceding discussion, just Simon
unilaterally deciding that this logging was required for debugging
purposes. (There is a followup thread in -hackers arguing about the
message wording, but nobody questioned whether it should come out
unconditionally.)
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 falls
down now.
regards, tom lane
On Mon, Jan 17, 2011 at 1:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Mon, Jan 17, 2011 at 17:46, Tom Lane <tgl@sss.pgh.pa.us> 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 given that things are the
way they are, clearly somebody else didn't agree as well - though I've
been unable to locate the original discussion if there was one.The existing behavior dates from here:
http://archives.postgresql.org/pgsql-committers/2010-03/msg00245.phpAs best I can tell there was no preceding discussion, just Simon
unilaterally deciding that this logging was required for debugging
purposes. (There is a followup thread in -hackers arguing about the
message wording, but nobody questioned whether it should come out
unconditionally.)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 falls
down now.
On a busy system, you could have a pretty high rate of messages
spewing forth for regular connections - that's a lot to wade through
if all you really want to see are the replication connections, which
should be much lower volume. But I guess now that we have
pg_stat_replication it's a little easier to see the status of
replication anyway. On the whole I've found the default setting here
very pleasant, so I'm reluctant to change it, but it sounds like I
might be out-voted.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 17.01.2011 21:04, Robert Haas wrote:
On Mon, Jan 17, 2011 at 1:57 PM, Tom Lane<tgl@sss.pgh.pa.us> 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 falls
down now.On a busy system, you could have a pretty high rate of messages
spewing forth for regular connections - that's a lot to wade through
if all you really want to see are the replication connections, which
should be much lower volume. But I guess now that we have
pg_stat_replication it's a little easier to see the status of
replication anyway. On the whole I've found the default setting here
very pleasant, so I'm reluctant to change it, but it sounds like I
might be out-voted.
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-side message is ok, we have a tradition of being more
verbose during recovery, we also emit the "restored log file \"%s\" from
archive" message for every WAL segment restored from archive for example.
We could turn log_connections into an enum, like log_statement:
log_connections = 'none' # none, replication, regular, all
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
On Tue, Jan 18, 2011 at 4:15 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> 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-side message is ok, we have a tradition of being more verbose during
recovery, we also emit the "restored log file \"%s\" from archive" message
for every WAL segment restored from archive for example.We could turn log_connections into an enum, like log_statement:
log_connections = 'none' # none, replication, regular, all
+1
We should treat log_disconnections the same?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
On Tue, Jan 18, 2011 at 08:21, Fujii Masao <masao.fujii@gmail.com> wrote:
On Tue, Jan 18, 2011 at 4:15 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> 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-side message is ok, we have a tradition of being more verbose during
recovery, we also emit the "restored log file \"%s\" from archive" message
for every WAL segment restored from archive for example.We could turn log_connections into an enum, like log_statement:
log_connections = 'none' # none, replication, regular, all
It almost seems overkill, but probably less so than a completely new guc :)
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
log the connection for...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Tue, Jan 18, 2011 at 5:17 PM, Magnus Hagander <magnus@hagander.net> 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
log the connection for...
Maybe true. But, at least for me, it's more intuitive to provide both as
enum parameters.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
On Tue, Jan 18, 2011 at 10:56, Fujii Masao <masao.fujii@gmail.com> wrote:
On Tue, Jan 18, 2011 at 5:17 PM, Magnus Hagander <magnus@hagander.net> 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
log the connection for...Maybe true. But, at least for me, it's more intuitive to provide both as
enum parameters.
Is there *any* usecase for setting them differently though? (other
than connections being <something> and disconnectoins being <none>?)
If not, aren't we just encouraging people to configure in a way that
makes no sense?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> 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? If not, why not? If we go through with something
fancy on the connection side, are we going to invent the same extra
complexity for log_disconnections? And if we do, what happens when
they're set inconsistently?
regards, tom lane
On Tue, Jan 18, 2011 at 2:15 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> 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. All right, I withdraw my objection. Let's just make
it all controlled by log_connections and go home.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
