Re: Configure problems on Solaris 2.7, pgsql 7.02 and 7.03 - Mailing list pgsql-hackers

From Ciaran Johnston
Subject Re: Configure problems on Solaris 2.7, pgsql 7.02 and 7.03
Date
Msg-id 3AD1F7EB.10239472@eei.ericsson.se
Whole thread Raw
In response to Configure problems on Solaris 2.7, pgsql 7.02 and 7.03  (Ciaran Johnston <Ciaran.Johnston@eei.ericsson.se>)
List pgsql-hackers
Mathijs Brands wrote:

> <SNIP>
>
> If you want to start running your production machine in august, it would
> be a very good idea to start using 7.1 now, since the stable release will
> most likely be out before then (probably april or early may).
>
> You seem to be using the Cygnus version of GCC. I'm not sure that will
> work ok, although it most likely does. The version of make and sed you're
> using are ok, so they shouldn't be causing your problems.
>
> Since it took me a couple of days to respond, it's possible that you've
> already resolved this problem. Have you? If not, you might try a binary
> distribution of pgsql instead. Or you could mail me the errors you're
> receiving. Maybe I can figure it out. No promises though.

Thanks, and thanks to all who responded. I experimented with a couple of configs and
finally went back to 7.0.3 and edited the configure script so that it didn't pass 'cc
--version' to sed (cheers to Tom Lane for pointing out the multiple-line output).
This worked and compiled, but postmaster gave me a nasty memory error which the FAQ
was able to provide a workaround for - shmget failed (invalid argument) was the
error. Seems my kernel isn't properly configured for postGres (along with all the
other things that are wrong with my system). I'm currently passing -N 16 -B 32 to the
postmaster and it is running - haven't tested it yet tho'. Are there optimum
parameters for these numbers, before I get around to getting my sysadmins to fix my
kernel for me? The testing should really be finished by next week and there's no way
they'll get it right before then. Also how much difference will this make? I'm
noticing slower queries but better scaleability to bigger tables than MySQL at the
minute, although my tests were far from optimised, and I have only just come back to
this.

I could probably have got 7.1RC2 working as well, I was just hoping the above error
was specific to that version and not to my system :-). When we set up the proper test
environment (which won't be for a few weeks), we'll probably use that (assuming
no-one here decides to spend 50 grand on Oracle, or MySQL doesn't suddenly pip the
post in the tests :-).

Thanks again.

Ciaran.

--
Ciaran Johnston
Ericsson Systems Expertise Ltd.,
Athlone
Co. Westmeath
Eire

email: Ciaran.Johnston@eei.ericsson.se
Phone: +353 902 31274





pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: timeout on lock feature
Next
From: Bruce Momjian
Date:
Subject: Re: "--tuning" compile and runtime option (?)