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
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 |