Обсуждение: 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
Re: [HACKERS] Re: setsockopt(SO_REUSEADDR) (Re: Call for porting reports)
От
"Kardos, Dr. Andreas"
Дата:
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