Horton
Menu

Thread

  1. pq_setkeepalives* functions

    Jaime Casanova <jcasanov@systemguards.com.ec> — 2010-03-13T04:48:24Z

    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 but for consistency with
the other two :)

-- 
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

  2. Re: pq_setkeepalives* functions

    Bruce Momjian <bruce@momjian.us> — 2010-03-13T15:35:50Z

    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
> conditional, doesn't seems to affect anything but for consistency with
> the other two :)
> 

Thanks, applied.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  PG East:  http://www.enterprisedb.com/community/nav-pg-east-2010.do

  3. Re: pq_setkeepalives* functions

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-03-13T16:24:30Z

    Bruce Momjian <bruce@momjian.us> 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 consistency.

			regards, tom lane

  4. Re: pq_setkeepalives* functions

    Bruce Momjian <bruce@momjian.us> — 2010-03-13T16:40:46Z

    Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> 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 consistency.

Well, it makes it like some of the existing functions, but not like
others.  This applied patch fixes them all.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  PG East:  http://www.enterprisedb.com/community/nav-pg-east-2010.do

  5. Re: pq_setkeepalives* functions

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-03-13T16:44:21Z

    Bruce Momjian <bruce@momjian.us> 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 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.

			regards, tom lane

  6. Re: pq_setkeepalives* functions

    Bruce Momjian <bruce@momjian.us> — 2010-03-13T16:56:57Z

    Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> 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 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.

OK, reverted.  Let me study the entire file.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  PG East:  http://www.enterprisedb.com/community/nav-pg-east-2010.do

  7. Re: pq_setkeepalives* functions

    Bruce Momjian <bruce@momjian.us> — 2010-03-13T16:57:33Z

    Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <bruce@momjian.us> 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 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.
> 
> OK, reverted.  Let me study the entire file.

Clarification, both changes reverted.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  PG East:  http://www.enterprisedb.com/community/nav-pg-east-2010.do

  8. Re: pq_setkeepalives* functions

    Bruce Momjian <bruce@momjian.us> — 2010-03-13T17:02:06Z

    Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> 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 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.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  PG East:  http://www.enterprisedb.com/community/nav-pg-east-2010.do

  9. Re: pq_setkeepalives* functions

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-03-13T17:10:47Z

    Bruce Momjian <bruce@momjian.us> 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.

AFAICS there is no issue, and the code is fine as-is.

Modifying the "get" functions as you propose would be harmless, but it's
also not an improvement, since it would result in redundant code in the
functions when those macros aren't defined.

I don't see any real advantage in making the set and get functions
look slightly more alike.  They're doing different things.

			regards, tom lane

  10. Re: pq_setkeepalives* functions

    Bruce Momjian <bruce@momjian.us> — 2010-03-13T17:38:33Z

    Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> 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.
> 
> AFAICS there is no issue, and the code is fine as-is.
> 
> Modifying the "get" functions as you propose would be harmless, but it's
> also not an improvement, since it would result in redundant code in the
> functions when those macros aren't defined.
> 
> I don't see any real advantage in making the set and get functions
> look slightly more alike.  They're doing different things.

OK, thanks for the analysis.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  PG East:  http://www.enterprisedb.com/community/nav-pg-east-2010.do

  11. Re: pq_setkeepalives* functions

    Jaime Casanova <jcasanov@systemguards.com.ec> — 2010-03-13T20:15:06Z

    On Sat, Mar 13, 2010 at 12:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Bruce Momjian <bruce@momjian.us> 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.
>
> AFAICS there is no issue, and the code is fine as-is.
>

ah! now i see this clearer... sorry for the noise

-- 
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157