Re: Replication logging

On Mon, Jan 17, 2011 at 16:31, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Jan 17, 2011 at 10:12 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> On Mon, Jan 17, 2011 at 16:03, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Mon, Jan 17, 2011 at 8:58 AM, Magnus Hagander <magnus(at)hagander(dot)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/