Re: Yet another failure mode in pg_upgrade - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Yet another failure mode in pg_upgrade
Date
Msg-id 20120901183506.GA13604@momjian.us
Whole thread Raw
In response to Re: Yet another failure mode in pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Yet another failure mode in pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Yet another failure mode in pg_upgrade  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Sat, Sep  1, 2012 at 02:23:22PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > +     /*
> > +      *    Report the Unix domain socket directory location to the postmaster.
> > +      */
> 
> "Report" seems entirely the wrong verb there.
> 
> > + #define LISTEN_STR    " -c listen_addresses=''"
> > + 
> > +     /* Have a sockdir to use? */
> > +     if (strlen(os_info.sockdir) != 0)
> > +         snprintf(socket_string, sizeof(socket_string) - strlen(LISTEN_STR),
> > +             " -c %s='%s'",
> > +             (GET_MAJOR_VERSION(cluster->major_version) < 903) ?
> > +                 "unix_socket_directory" : "unix_socket_directories",
> > +             os_info.sockdir);
> > +     
> > +     /* prevent TCP/IP connections */
> > +     strcat(socket_string, LISTEN_STR);
> 
> IMO this would be simpler and more readable if you got rid of the LISTEN_STR
> #define and just included -c listen_addresses='' in the snprintf format
> string.  The comment for the whole thing should be something like
> "If we have a socket directory to use, command the postmaster to use it,
> and disable TCP/IP connections altogether".

Well, you only want the unix_socket* if sockdir is defined, but you want
LISTEN_STR unconditionally, even if there is no sockdir.  Not sure how
that could cleanly be in a single snprintf.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Yet another failure mode in pg_upgrade
Next
From: Tom Lane
Date:
Subject: Re: Yet another failure mode in pg_upgrade