Thread: RE: [HACKERS] Re: Problems compiling version 7
This reminds me of a problem I once had. I was trying to "make" the documentation, but zcat kept failing because the Solaris version does not work the same as the GNU version. So I installed the GNU zcat, ran configure again, but still make was failing because of zcat... I found that once configure has found an item it is looking for, it caches it in config.cache. From then on, even if you do a "make clean", configure still uses things from config.cache. To have configure essentially start from scratch and "re-find" things, you must run "make distclean", which will also delete config.cache. After doing this, and running configure again, everything worked fine. Hope this helps, Phil Culberson DAT Services -----Original Message----- From: Peter Eisentraut [mailto:peter_e@gmx.net] Sent: Wednesday, May 10, 2000 2:25 PM To: Tom Lane Cc: Travis Bauer; pgsql-general@postgresql.org; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Re: [GENERAL] Problems compiling version 7 Tom Lane writes: > >> dnl Check tr flags to convert from lower to upper case > The results *are* used, in backend/utils/Gen_fmgrtab.sh.in (and > apparently nowhere else). Ah, I see. Substituting into source files directly from configure ... very evil... (Before you ask why: What if I change Gen_fmgrtab.sh.in, do I have to re-configure?) > But we haven't yet figured out Travis' problem: why is the configure > test failing? Useless or not, I don't see why it's falling over... Unfortunately he cut off the line where it says `checking for tr'. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Thanks for all the advice. The following was _exactly_ the problem. I had tried to compile this source code in a recent version of solaris. It compiled flawlessly, but postmaster wouldn't start up. So I just did a secure shell to a linux machine, ran "make clean" from the same directory, and ran configure. I thought make clean would erase all except the distribution files. It compiled, installed, and I used psql to get into the database. I haven't tested the ODBC or the JDBC interfaces yet (I'm using both in my projects), but all seems to be working. Thanks, ---------------------------------------------------------------- Travis Bauer | CS Grad Student | IU |www.cs.indiana.edu/~trbauer ---------------------------------------------------------------- On Wed, 10 May 2000, Culberson, Philip wrote: > > I found that once configure has found an item it is looking for, it caches > it in config.cache. From then on, even if you do a "make clean", configure > still uses things from config.cache. >
In general this can be solved by doing a
make distclean
which should be included in the makefile, which is supposed to kill all
of the config.cache and generated targets created in the configure step.
Sorry if this is already answered, just joined.
-bill
On Wed, 10 May 2000, Travis Bauer wrote:
> Thanks for all the advice. The following was _exactly_ the problem. I
> had tried to compile this source code in a recent version of solaris. It
> compiled flawlessly, but postmaster wouldn't start up. So I just did a
> secure shell to a linux machine, ran "make clean" from the same directory,
> and ran configure. I thought make clean would erase all except the
> distribution files. It compiled, installed, and I used psql
> to get into the database. I haven't tested the ODBC or the JDBC
> interfaces yet (I'm using both in my projects), but all seems to be
> working.
>
> Thanks,
>
> ----------------------------------------------------------------
> Travis Bauer | CS Grad Student | IU |www.cs.indiana.edu/~trbauer
> ----------------------------------------------------------------
>
> On Wed, 10 May 2000, Culberson, Philip wrote:
>
> >
> > I found that once configure has found an item it is looking for, it caches
> > it in config.cache. From then on, even if you do a "make clean", configure
> > still uses things from config.cache.
> >
>
>
Travis Bauer <trbauer@indiana.edu> writes:
> Thanks for all the advice. The following was _exactly_ the problem. I
> had tried to compile this source code in a recent version of solaris. It
> compiled flawlessly, but postmaster wouldn't start up. So I just did a
> secure shell to a linux machine, ran "make clean" from the same directory,
> and ran configure. I thought make clean would erase all except the
> distribution files.
Ah, bingo. "make clean" doesn't erase the configure-produced files,
and in particular not config.cache, so you were getting polluted by
configure test results from the other platform. "make distclean" is
the thing to do before reconfiguring. AFAIK this is a pretty
standard convention for applications that use configure scripts.
(Actually, it'd probably work to just delete config.cache, but you may
as well do the "make distclean" instead. I know that works.)
Next question: do you feel like pursuing the failure on solaris?
That should've worked...
regards, tom lane
Hi, What is the recommended way to reload a database in 6.5.3? Right now I tried something like: psql -f testfile -u test > /dev/null 2>&1 (then enter username and password, and wait) (testfile is a dump of a 36MB database) And I think it works, but while it is running it affects the performance of other unrelated databases severely. Should this be happening? Top only shows four or so backends running, but the webapps are like grinding down to 20 seconds or more per page. Normally our webapps can do 12 hits/sec or so, so such a drastic drop is surprising. This is on a PIII 500MHz 512MB, SCSI 9GB HDD system. Also when I did a 30MB psql level copy (\copy) into a test database and table, somehow the performance of _other_ databases was bad until I did a vacuum (which took ages). This was rather surprising. I'll probably switch to 7.0 soon and see if the issue crops up. I hope copies are much faster in 7.0. Should I turn off fsync when doing bulk copies? I'm worried that if the backend crashes duing the copy, the other databases may get corrupted. Any comments? Thanks, Link.
Tom, I read the FAQ on solaris, and the error I got was the IPCMemoryCreate error mentioned there. If I asked the system admin's they may reboot a machine for me to fix that error, but it's just as easy for me to use Linux box on our network as it is to use a Solaris box. Thanks again for all the help. ---------------------------------------------------------------- Travis Bauer | CS Grad Student | IU |www.cs.indiana.edu/~trbauer ---------------------------------------------------------------- On Thu, 11 May 2000, Tom Lane wrote: > > Next question: do you feel like pursuing the failure on solaris? > That should've worked... > > regards, tom lane >
Lincoln Yeoh wrote: > > Actually, say if I use postgresql on a journalling file system, would this > problem go away? e.g. I just lose data not written, but the database will > be at a known uncorrupted state, consistent with logs. Hmm, someone may have to correct me on this but last time I checked all the journalling filesystems currently available journalled *filesystem* *metadata*. IOW, after a crash, the filesystem structure will be intact, but your database maybe completely corrupt. Anyway, how does the filesystem driver know what is a consistant state for the database? For that postgres would have to do it's own journalling, right? -- Martijn van Oosterhout <kleptog@cupid.suninternet.com> http://cupid.suninternet.com/~kleptog/
Lincoln Yeoh <lylyeoh@mecomb.com> writes:
> Actually, say if I use postgresql on a journalling file system, would this
> problem go away?
Not unless your kernel guarantees to write dirty buffers to disk in the
order they were dirtied, which would be a fairly surprising thing for it
to guarantee IMHO; that's not how Unix buffer caches normally behave.
regards, tom lane
> Lincoln Yeoh wrote: > > > > Actually, say if I use postgresql on a journalling file system, would this > > problem go away? e.g. I just lose data not written, but the database will > > be at a known uncorrupted state, consistent with logs. > > Hmm, someone may have to correct me on this but last time I checked all > the > journalling filesystems currently available journalled *filesystem* > *metadata*. IOW, after a crash, the filesystem structure will be intact, > but your database maybe completely corrupt. The buffers remain sitting in the file system buffers, not on disk in a dick crash. That is the problem. Journaling does not change this. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026