Skip site navigation (1) Skip section navigation (2)

Re: [COMMITTERS] pgsql: Add GUC variables to control keep-alive

From: Andrew - Supernews <andrew+nonews(at)supernews(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Add GUC variables to control keep-alive
Date: 2005-08-01 04:17:38
Message-ID: slrnder8j1.bj3.andrew+nonews@trinity.supernews.net (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On 2005-08-01, Oliver Jowett <oliver(at)opencloud(dot)com> wrote:
> There's no dependency on socket PF mentioned there, and the obvious
> reading of that text is that a "level identifier" uniquely identifies
> the "protocol controlling the option" -- so IPPROTO_TCP unambiguously
> means "the TCP protocol".

You're reading more into the spec than is present. It should be obvious
that the existence of, number of and organization of any layers that might
happen to exist below the socket layer is entirely dependent on the
protocol family. The fact that PF-dependent constants are used for
referring to such layers should reinforce this.

> Having multiple socket-PF-dependent namespaces which might overlap is
> just asking for hard-to-find bugs (if you accidentally manage to use the
> wrong namespace for the socket, you run the risk of getting weird
> behaviour rather than an error).

Think about what happens when you add a brand-new protocol family.

-- 
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-08-01 04:28:55
Subject: Re: Remote administration functionality
Previous:From: Oliver JowettDate: 2005-08-01 03:24:09
Subject: Re: [COMMITTERS] pgsql: Add GUC variables to control keep-alive

pgsql-committers by date

Next:From: User ShacharDate: 2005-08-01 11:35:21
Subject: oledb - tests: Imported Sources
Previous:From: Tom LaneDate: 2005-08-01 04:03:59
Subject: pgsql: Add ALTER object SET SCHEMA capability for a limited but useful

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group