Re: [HACKERS] pq_setkeepalives* functions

2010-03-13 Thread Jaime Casanova
On Sat, Mar 13, 2010 at 12:10 PM, Tom Lane wrote: > Bruce Momjian writes: >> Tom Lane wrote: >>> This is making things worse, not better.  You have just changed the >>> behavior, and not in a good way.  Formerly these were no-ops on >>> a unix socket connection, and now they can throw errors. > >

Re: [HACKERS] pq_setkeepalives* functions

2010-03-13 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> This is making things worse, not better. You have just changed the > >> behavior, and not in a good way. Formerly these were no-ops on > >> a unix socket connection, and now they can throw errors. > > > Is this the proper way to f

Re: [HACKERS] pq_setkeepalives* functions

2010-03-13 Thread Tom Lane
Bruce Momjian writes: > Tom Lane wrote: >> This is making things worse, not better. You have just changed the >> behavior, and not in a good way. Formerly these were no-ops on >> a unix socket connection, and now they can throw errors. > Is this the proper way to fix the issue? Patch attached.

Re: [HACKERS] pq_setkeepalives* functions

2010-03-13 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> This makes the function *not* like the other two, rather than > >> improving consistency. > > > Well, it makes it like some of the existing functions, but not like > > others. This applied patch fixes them all. > > This is making

Re: [HACKERS] pq_setkeepalives* functions

2010-03-13 Thread Bruce Momjian
Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian writes: > > > Tom Lane wrote: > > >> This makes the function *not* like the other two, rather than > > >> improving consistency. > > > > > Well, it makes it like some of the existing functions, but not like > > > others. This applied patch

Re: [HACKERS] pq_setkeepalives* functions

2010-03-13 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> This makes the function *not* like the other two, rather than > >> improving consistency. > > > Well, it makes it like some of the existing functions, but not like > > others. This applied patch fixes them all. > > This is making

Re: [HACKERS] pq_setkeepalives* functions

2010-03-13 Thread Tom Lane
Bruce Momjian writes: > Tom Lane wrote: >> This makes the function *not* like the other two, rather than >> improving consistency. > Well, it makes it like some of the existing functions, but not like > others. This applied patch fixes them all. This is making things worse, not better. You hav

Re: [HACKERS] pq_setkeepalives* functions

2010-03-13 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian writes: > > Jaime Casanova wrote: > >> but in pq_setkeepalivesinterval() the #DEFINE is after the > >> conditional, doesn't seems to affect anything but for consistency with > >> the other two :) > > > Thanks, applied. > > This makes the function *not* like the ot

Re: [HACKERS] pq_setkeepalives* functions

2010-03-13 Thread Tom Lane
Bruce Momjian writes: > Jaime Casanova wrote: >> but in pq_setkeepalivesinterval() the #DEFINE is after the >> conditional, doesn't seems to affect anything but for consistency with >> the other two :) > Thanks, applied. This makes the function *not* like the other two, rather than improving con

Re: [HACKERS] pq_setkeepalives* functions

2010-03-13 Thread Bruce Momjian
Jaime Casanova wrote: > Hi, > > In 2 of 3 pq_setkeepalives* functions we have the #DEFINE involving > even this conditional: > """ > if (port == NULL || IS_AF_UNIX(port->laddr.addr.ss_family)) > return STATUS_OK; > """ > > but in pq_setkeepalivesinterval() the #DEFINE is after the > c

[HACKERS] pq_setkeepalives* functions

2010-03-12 Thread Jaime Casanova
Hi, In 2 of 3 pq_setkeepalives* functions we have the #DEFINE involving even this conditional: """ if (port == NULL || IS_AF_UNIX(port->laddr.addr.ss_family)) return STATUS_OK; """ but in pq_setkeepalivesinterval() the #DEFINE is after the conditional, doesn't seems to affect anything