Re: TCP keepalive support for libpq - Mailing list pgsql-hackers

From Robert Haas
Subject Re: TCP keepalive support for libpq
Date
Msg-id 603c8f071002150818n32c617b0h126417514078689d@mail.gmail.com
Whole thread Raw
In response to Re: TCP keepalive support for libpq  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: TCP keepalive support for libpq
List pgsql-hackers
On Mon, Feb 15, 2010 at 11:15 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Mon, Feb 15, 2010 at 11:00 AM, Tom Lane <tgl@sss.pgh.pa.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.

Mmm.  OK, fair enough.

...Robert


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: TCP keepalive support for libpq
Next
From: Tom Lane
Date:
Subject: Re: Streaming Replication on win32