Thread: Re: setsockopt(SO_REUSEADDR) (Re: Call for porting reports)

Yes, if
#define ONLY_REUSE_INET_SOCKETS
is included in solaris_sparc.h as in sco.h the postmaster can be started.

But except the libpq++, inet_aton() and SO_REUSEADDR problems there are more
problems:

1) psql cannot be made since perl is used to generate sql_help.h. There is
no perl on this machine. So configure doesn't help if perl is used anyway.

2) After I have copied sql_help.h from another platforms I could build psql,
but not start:

psql: PQconnectPoll() --  couldn't send startup packet: errno=22
Invalid argument

TCP/IP or Unix domain sockets doesn't matter.

Regards,
Andreas Kardos

-----Ursprüngliche Nachricht-----
Von: Tom Lane <tgl@sss.pgh.pa.us>
An: Kardos, Dr. Andreas <kardos@repas-aeg.de>
Cc: <hackers@postgresql.org>; <pgsql-ports@postgresql.org>
Gesendet: Dienstag, 11. April 2000 16:40
Betreff: setsockopt(SO_REUSEADDR) (Re: Call for porting reports)


> "Kardos, Dr. Andreas" <kardos@repas-aeg.de> writes:
> > SunOS 5.4 (sparc-sun-solaris) with native Sun compilers:
> > 3) The postmaster cannot be started:
>
> > sun2$ postmaster -i
> > FATAL: StreamServerPort: setsockopt(SO_REUSEADDR) failed: Protocol error
> > /usr/local/pgsql/bin/postmaster: cannot create UNIX stream port
>
> > Does SunOS not support Unix domain sockets? The same error appears
without
> > the -i option.
>
> There is an
> #ifdef ONLY_REUSE_INET_SOCKETS
> check to skip that call, but the symbol only seems to be defined for
> sco.  Now we see that Solaris doesn't like that call either.
>
> At the time the SCO patch was proposed, I thought we should just
> unconditionally skip the setsockopt(SO_REUSEADDR) call for the Unix-
> domain socket, because AFAIK it doesn't mean anything for that domain
> anyway.  Can anyone think of a reason not to do so now?  Seems to me
> that trying to apply a nonapplicable option is just asking for trouble.
>
> regards, tom lane
>

"Kardos, Dr. Andreas" <kardos@repas-aeg.de> writes:
> 1) psql cannot be made since perl is used to generate sql_help.h. There is
> no perl on this machine. So configure doesn't help if perl is used anyway.

sql_help.h is (or should be) part of the distribution tarball.  Was it
not present, or perhaps out-of-date?  In any case the Makefile for psql
looks like it will not try to regenerate sql_help.h unless configure
found perl.

> psql: PQconnectPoll() --  couldn't send startup packet: errno=22
> Invalid argument

> TCP/IP or Unix domain sockets doesn't matter.

That's odd.  Can you get in there with a debugger (or add some printfs)
and see what's going wrong exactly?  That message can only come from
one place, but the subroutine it's reporting failure of does several
kernel calls.

            regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> wrote:

> "Kardos, Dr. Andreas" <kardos@repas-aeg.de> writes:
> > 1) psql cannot be made since perl is used to generate sql_help.h. There
is
> > no perl on this machine. So configure doesn't help if perl is used
anyway.
>
> sql_help.h is (or should be) part of the distribution tarball.  Was it
> not present, or perhaps out-of-date?  In any case the Makefile for psql
> looks like it will not try to regenerate sql_help.h unless configure
> found perl.

The entries in Makefile.global are
Makefile.global:USE_PERL= false
Makefile.global:PERL= perl

PERL= perl seems to be static (see Makefile.global.in)

Since in psql/Makefile only PERL but not USE_PERL is checked, perl will be
called always if sql_help.h is not present. But since sql-help.h is in the
distribution tarball this ist not really a problem.

> > psql: PQconnectPoll() --  couldn't send startup packet: errno=22
> > Invalid argument
>
> > TCP/IP or Unix domain sockets doesn't matter.
>
> That's odd.  Can you get in there with a debugger (or add some printfs)
> and see what's going wrong exactly?  That message can only come from
> one place, but the subroutine it's reporting failure of does several
> kernel calls.

pqFlush() fails because send() fails with the following parameters:

send(sock = 3, ptr = 4a320, len = 296, 0) => -1
errno = 22 (EINVAL)

The man pages sais that EINVAL may occure only in sendto() but not in
send()!!!
The parameters seem to be OK for me.
There is the same behaviour for UNIX domain and for TCP sockets.
????

BTW, configure picks up the wrong template solaris_sparc_gcc instead of
solaris_sparc_cc. But this is probably not the cause of the problem.

We don't really need Solaris support here. I only wanted to give it a try
due to the call for porting reports.

It seems to me that the Mailing lists hang again a little bit. I don't get
the mails back I have sent. Furthermore here is much less traffic as
usually.

Regards,
Andreas Kardos

"Kardos, Dr. Andreas" <kardos@repas-aeg.de> writes:
> The entries in Makefile.global are
> Makefile.global:USE_PERL= false
> Makefile.global:PERL= perl
> PERL= perl seems to be static (see Makefile.global.in)
> Since in psql/Makefile only PERL but not USE_PERL is checked, perl will be
> called always if sql_help.h is not present.

OK, I think that's a bug in the Makefile: it should be checking USE_PERL
to decide whether to create a build rule for sql-help.h (Peter, do you
agree)?

> pqFlush() fails because send() fails with the following parameters:

> send(sock = 3, ptr = 4a320, len = 296, 0) => -1
> errno = 22 (EINVAL)

> The man pages sais that EINVAL may occure only in sendto() but not in
> send()!!!
> The parameters seem to be OK for me.
> There is the same behaviour for UNIX domain and for TCP sockets.
> ????

No idea here, either.  Anyone?

            regards, tom lane

Tom Lane writes:

> "Kardos, Dr. Andreas" <kardos@repas-aeg.de> writes:
> > 1) psql cannot be made since perl is used to generate sql_help.h. There is
> > no perl on this machine. So configure doesn't help if perl is used anyway.
>
> sql_help.h is (or should be) part of the distribution tarball.  Was it
> not present, or perhaps out-of-date?  In any case the Makefile for psql
> looks like it will not try to regenerate sql_help.h unless configure
> found perl.

That was the idea but it doesn't quite work this way. The variable PERL is
hard-coded to be "perl" in Makefile.global.in, no testing is actually
done. (Wasn't my idea.) This will essentially prevent building psql on
machines without Perl *if sql_help.h needs to be rebuilt* (which it
shouldn't).

This leads to a second problem, however. There's a subtle difference
between targets of the form

sql_help.h: # no dependencies, no action

and

sql_help.h: ; # no dependencies, "do nothing" as action

The latter would be the righter thing to do because the former will
consider sql_help.h updated whenever the rule is run. This will in turn
lead to recompilation of help.c and thus psql for every make run. I just
learned that the other day.

I have a fix for both issues (the first involves AC_CHECK_PROGS, the
second is obvious), should I go for it?


--
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

Tom Lane writes:

> OK, I think that's a bug in the Makefile: it should be checking
> USE_PERL to decide whether to create a build rule for sql-help.h
> (Peter, do you agree)?

No. USE_PERL depends on configure --with-perl, which is something
completely different. The answer is to use AC_CHECK_PROGS(perl, PERL). The
alternative answer is to use perl unconditionally and say "too bad, if you
are not using the distribution you need Perl". The latter actually looks
cleaner to me now. (After all, the only time the file is rebuilt is when
the docs change (what user does that?) or the very first time. In the
latter case doing nothing is not really the answer either.)

(See also earlier message about another bug.)

Have we reached any consensus on making ONLY_REUSE_INET_SOCKETS the
default (i.e., removing it)? I'm no socket sort of guy but the
documentation clearly states that address reusing is only defined for Inet
sockets. I can run tests tomorrow (i.e. in about 10 hours) to see if it
does any good. Do I have a go?

--
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> OK, I think that's a bug in the Makefile: it should be checking
>> USE_PERL to decide whether to create a build rule for sql-help.h
>> (Peter, do you agree)?

> No. USE_PERL depends on configure --with-perl, which is something
> completely different. The answer is to use AC_CHECK_PROGS(perl, PERL).

That doesn't strike me as sufficient; it is quite likely that that will
find a perl 4.  Does your help-building script run on perl 4?  If not,
you need a more careful check on what sort of perl you have found.
If you want to test for perl 5, go for it.  If not, look at USE_PERL,
which puts it on the user's shoulders to make sure that he's got a
compatible perl.

> The
> alternative answer is to use perl unconditionally and say "too bad, if you
> are not using the distribution you need Perl". The latter actually looks
> cleaner to me now. (After all, the only time the file is rebuilt is when
> the docs change (what user does that?) or the very first time. In the
> latter case doing nothing is not really the answer either.)

No, not good.  We've seen a number of problems due to timestamps being
out of sync in tarballs.  It's better to build psql with a slightly
out-of-date helpfile than to fail to build it at all.  So, the Makefile
should be set up to apply the build rule if a usable perl is available,
otherwise not.

> Have we reached any consensus on making ONLY_REUSE_INET_SOCKETS the
> default (i.e., removing it)? I'm no socket sort of guy but the
> documentation clearly states that address reusing is only defined for Inet
> sockets.

I've stated twice now that I thought that we should never try to do
setsockopt(SO_REUSEADDR) on the Unix socket.  I am going to remove
the ifdef check tomorrow, unless you beat me to it.

            regards, tom lane

On Thu, 13 Apr 2000, Tom Lane wrote:

> That doesn't strike me as sufficient; it is quite likely that that
> will find a perl 4.  Does your help-building script run on perl 4?

No idea. Does anyone have Perl 4 and can try it (and fix it)? Surely Perl
4 supports regular expressions and flow control.

> If not, look at USE_PERL, which puts it on the user's shoulders to
> make sure that he's got a compatible perl.

But USE_PERL determines whether to build the Pg.pm module. Your proposal
will lead to most obvious failures if someone checks out the CVS tree and
builds without --with-perl. The solution is to test for the required
program, not to overload configuration options.

> I've stated twice now that I thought that we should never try to do
> setsockopt(SO_REUSEADDR) on the Unix socket.  I am going to remove
> the ifdef check tomorrow, unless you beat me to it.

Didn't make a difference. :( I'm out of wisdom now, so my verdict is don't
use Unix sockets on this platform. Now if there was only an option to turn
them off ...

Residual observations:

1) The broken pipe errors I am talking about always occur after the system
has been up and used a little while. That is, in the parallel regression
tests I always get the failures in the last half or third, mostly after
the "misc" test.

2) Doing a chmod a-x /tmp/.s.PGSQL.65432 right after postmaster startup
seems to cut down on the number of occurences of this problem.


--
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
> On Thu, 13 Apr 2000, Tom Lane wrote:
>> That doesn't strike me as sufficient; it is quite likely that that
>> will find a perl 4.  Does your help-building script run on perl 4?

> No idea. Does anyone have Perl 4 and can try it (and fix it)? Surely Perl
> 4 supports regular expressions and flow control.

perl 4.0.36 generates half a dozen minor-looking syntax errors.  Looks
like perl 5 is more forgiving about where you put parentheses.  Also
perl4 doesn't have "my()", only "local()".  Should be easy to fix;
I'll try this weekend.

Given that, I agree that configure should be fixed to look for a perl,
and then the psql Makefile should enable the build rule only if one
was found.  You want to handle that part?

            regards, tom lane