Re: TCP keepalive support for libpq
От | Robert Haas |
---|---|
Тема | Re: TCP keepalive support for libpq |
Дата | |
Msg-id | 603c8f071002150818n32c617b0h126417514078689d@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: TCP keepalive support for libpq (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: TCP keepalive support for libpq
|
Список | 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 по дате отправления: