Re: TCP keepalive support for libpq

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Euler Taveira de Oliveira <euler(at)timbira(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Marko Kreen <markokr(at)gmail(dot)com>, Tollef Fog Heen <tollef(dot)fog(dot)heen(at)collabora(dot)co(dot)uk>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TCP keepalive support for libpq
Date: 2010-02-15 16:15:20
Message-ID: 151.1266250520@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Feb 15, 2010 at 11:00 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> If this were actually a low-risk patch I might think it was okay to try
>> to shoehorn it in now; but IME nothing involving making new use of
>> system-dependent APIs is ever low-risk. Look at Greg's current
>> embarrassment over fsync, a syscall I'm sure he thought he knew all
>> about.

> That's why I think we shouldn't change the default behavior, but
> exposing a new option that people can use or not as works for them
> seems OK.

That's assuming they get as far as having a working libpq to try it
with. I'm worried about the possibility of inducing compile or link
failures. "It works in the backend" doesn't give me that much confidence
about it working in libpq.

I'm all for this as a 9.1 submission, but let's not commit to trying to
debug it now. I would like a green buildfarm for awhile before we wrap
alpha4, and this sort of untested "it can't hurt" patch is exactly what
is likely to make things not green.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-02-15 16:18:40 Re: TCP keepalive support for libpq
Previous Message Magnus Hagander 2010-02-15 16:12:14 Re: TCP keepalive support for libpq