Re: Keepalive-related socket options under FreeBSD 9, 10

From: Palle Girgensohn <girgen(at)pingpong(dot)net>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Piotr Stefaniak <postgres(at)piotr-stefaniak(dot)me>
Subject: Re: Keepalive-related socket options under FreeBSD 9, 10
Date: 2014-07-02 15:58:39
Message-ID: EF975B1C-4CCA-445C-819A-E18E2D1900F8@pingpong.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Since upgrading FreeBSD from 8 to 9, I've noticed the following messages
> showing up in logs when a connection with pgAdmin3 is made:
>
> LOG: getsockopt(TCP_KEEPCNT) failed: Protocol not available
> STATEMENT: SELECT setting FROM pg_settings WHERE name IN ('autovacuum',
> 'track_counts')
> LOG: getsockopt(TCP_KEEPIDLE) failed: Protocol not available
> STATEMENT: SELECT setting FROM pg_settings WHERE name IN ('autovacuum',
> 'track_counts')
> LOG: getsockopt(TCP_KEEPINTVL) failed: Protocol not available
> STATEMENT: SELECT setting FROM pg_settings WHERE name IN ('autovacuum',
> 'track_counts')
>
> tcp_keepalives_idle, tcp_keepalives_interval, and tcp_keepalives_count
> are all set to the default (0), which means "system default".
>
> My guess as to what causes this:
>
> src/backend/libpq/pqcomm.c apparently assumes that if TCP_KEEPIDLE &
> friends are defined, then the respective options are readable, but
> according to man tcp, that is not the case for FreeBSD 9 (and 10):
>
> TCP_KEEPINIT
> This write-only setsockopt(2) option accepts a per-socket
> timeout argument of u_int in seconds, for new, non-estab-
> lished TCP connections. For the global default in mil-
> liseconds see keepinit in the MIB Variables section fur-
> ther down.
>
> As a work-around, I've set the keepalive options to the system defaults
> provided by man tcp.
>

Hi,

This only happens with some clients, right? I'm seeing it for only happens for some programs, like connecting from perl? I've seem discussions a while back about why they are read-only.

I see it to, but only for a perl connection, nothing for psql or the likes.

Do you have any suggestions for a patch for the port, in the mean while?

Palle

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-07-02 15:58:54 Re: slotname vs slot_name
Previous Message Stephen Frost 2014-07-02 15:49:34 Re: RLS Design