Connections on cluster not being logged
I have postgresql 9.4 on a cluster, hardware based. I need to be able to see which users are connecting to which database and when to be in compliance with our security policies. I have set the following in the postgresql.conf and did a pg_ctl reload: log_connections = on log_line_prefix = '%t [%p]:[%u]:[%h]-[%d] [%1-1]' Unfortunately, it doesn't seem to be logging the connections. This is what I have used on our non-clustered instances and it's working as expected. Have I missed something relating to logging on a cluster? The second node is strictly for automatice failover, so nothing is actually running there at the moment. Thank you in advance for any suggestions. Sandy
Re: Connections on cluster not being logged
Yes, they are in effect.
name |setting
-+---
log_connections | on
log_line_prefix | %t [%p]:[%u]:[%h]-[%d] [%1-1]
Sandy
On Mon, Jul 23, 2018 at 9:23 AM, Andreas Kretschmer wrote:
>
>
> Am 23.07.2018 um 17:14 schrieb Sandy Becker:
>
>> I have postgresql 9.4 on a cluster, hardware based. I need to be able to
>> see which users are connecting to which database and when to be in
>> compliance with our security policies.
>>
>> I have set the following in the postgresql.conf and did a pg_ctl reload:
>>
>> log_connections = on
>> log_line_prefix = '%t [%p]:[%u]:[%h]-[%d] [%1-1]'
>>
>
> should work, can you check if those settings are in effect?
>
> select name, setting from pg_settings where name in
> ('log_connections','log_line_prefix');
>
>
> Regards, Andreas
>
> --
> 2ndQuadrant - The PostgreSQL Support Company.
> www.2ndQuadrant.com
>
>
>
Re: Connections on cluster not being logged
Actually, the last entry in the log file was when I changed the name so it was consistent with our other servers. I'm pretty new to postgresql, so I'm not really sure what I should be looking for. It looks like we're logging only statements where log_min_duration_statement = 1000. That's all I'm seeing the logs for the past 30 days anyway. Sandy On Mon, Jul 23, 2018 at 10:00 AM, Andreas Kretschmer < andr...@a-kretschmer.de> wrote: > > > Am 23.07.2018 um 17:25 schrieb Sandy Becker: > >> Yes, they are in effect. >> > > strange. the logging is working? you can see other and actual entries in > the logfile? > > > Regards, Andreas > > -- > 2ndQuadrant - The PostgreSQL Support Company. > www.2ndQuadrant.com > >
Re: Connections on cluster not being logged
There is only one set of logs since it's a hardware cluster. The two nodes share the underlying database storage. Not sure why, but when the log rolled over this morning, connections started getting logged. All is good now. Thanks for your help. On Mon, Jul 23, 2018 at 1:58 PM, Adrian Klaver wrote: > On 07/23/2018 12:50 PM, Sandy Becker wrote: > Please reply to list also. > Ccing list. > > Two servers set up in a hardware cluster for automatic failover. That's >> all I know about it. >> > > Alright, so which server's logs are you looking at? > > Long term it would be a good thing to know how the cluster/failover is > setup, as that is something folks on this list are going to ask when > attempting to answer a question. Just trying to get ahead of the > inevitable:) > > >> On Mon, Jul 23, 2018 at 1:04 PM, Adrian Klaver > <mailto:adrian.kla...@aklaver.com>> wrote: >> >> On 07/23/2018 08:14 AM, Sandy Becker wrote: >> >> I have postgresql 9.4 on a cluster, hardware based. I need to >> be able to see which users are connecting to which database and >> when to be in compliance with our security policies. >> >> I have set the following in the postgresql.conf and did a pg_ctl >> reload: >> >>log_connections = on >>log_line_prefix = '%t [%p]:[%u]:[%h]-[%d] [%1-1]' >> >> Unfortunately, it doesn't seem to be logging the connections. >> This is what I have used on our non-clustered instances and it's >> working as expected. Have I missed something relating to >> logging on a cluster? The second node is strictly for >> automatice failover, so nothing is actually running there at the >> moment. >> >> >> Can you define what you mean by a cluster? >> >> >> >> >> Thank you in advance for any suggestions. >> >> Sandy >> >> >> >> -- Adrian Klaver >> adrian.kla...@aklaver.com <mailto:adrian.kla...@aklaver.com> >> >> >> > > -- > Adrian Klaver > adrian.kla...@aklaver.com >
