Melvin,

I promised to let you know results of my experiment, so here is goes:


tcp_keepalives_idle = 900
tcp_keepalives_interval=0
tcp_keepalives_count=0

Doesn't terminate connection to database in 15 minutes of inactivity of
psql prompt. So, it looks like that would work only for case if network
connection is broken and session left hanging. For psql prompt case looks
like pg_terminate_backend() would be the only solution.

Thanks,

Oleg



On Sun, Dec 20, 2015 at 11:33 AM, Melvin Davidson <melvin6...@gmail.com>
wrote:

> Actually, I'm not an expert on the tcp_keepalives, but I  believe the 
> tcp_keepalives_count
> should be 1, otherwise it will take 45 minutes minutes to timeout. Then
> again, I could be wrong.
>
> On Sun, Dec 20, 2015 at 12:28 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
>> oleg yusim <olegyu...@gmail.com> writes:
>> > Got it, thanks... Now, is it any protection in place currently against
>> > replacing Session ID (my understanding, it is kept in memory, belonging
>> to
>> > the session process) or against guessing Session ID (i.e. is Session ID
>> > generated using FIPS 140-2 compliant algorithms, or anything of that
>> sort)?
>>
>> I don't think Postgres even has any concept that matches what you seem
>> to think a Session ID is.
>>
>> If you're looking for communication security/integrity checking, that's
>> something we leave to other software such as SSL.
>>
>>                         regards, tom lane
>>
>>
>> --
>> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>>
>
>
>
> --
> *Melvin Davidson*
> I reserve the right to fantasize.  Whether or not you
> wish to share my fantasy is entirely up to you.
>

Reply via email to