On Mon, Jan 17, 2011 at 14:00, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Jan 17, 2011 at 1:53 AM, Magnus Hagander <mag...@hagander.net> wrote: >> On Mon, Jan 17, 2011 at 03:06, Robert Haas <robertmh...@gmail.com> wrote: >>> On Sun, Jan 16, 2011 at 9:19 AM, Magnus Hagander <mag...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
