Re: Replication logging - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Replication logging
Date
Msg-id AANLkTi=SqwLhWbuLtO5K5jyK0zsmxBnXNnKVitbUZVuu@mail.gmail.com
Whole thread Raw
In response to Re: Replication logging  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Replication logging
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.
Next
From: David Fetter
Date:
Subject: Re: SSI patch version 12