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

Wed, 10 May 2000 15:04:44 -0700
"Culberson, Philip" <philip.culberson@dat.com>
RE: [HACKERS] Re: Problems compiling version 7 
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.
> 


Wed, 10 May 2000 22:00:38 -0500 (EST)
Travis Bauer <trbauer@indiana.edu>
RE: [HACKERS] Re: Problems compiling version 7 - solved

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.
> > 
> 
> 

Wed, 10 May 2000 20:25:41 -0700 (PDT)
"William J. Mills" <wmills@netcom.com>
RE: [HACKERS] Re: Problems compiling version 7 - solved
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

Thu, 11 May 2000 01:36:47 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: Problems compiling version 7 - solved 
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.


Thu, 11 May 2000 15:32:27 +0800
Lincoln Yeoh <lylyeoh@mecomb.com>
Dumping and reloading stuff in 6.5.3
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
> 




Thu, 11 May 2000 08:39:32 -0500 (EST)
Travis Bauer <trbauer@indiana.edu>
Re: [HACKERS] Re: Problems compiling version 7 - solved 
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/

Tue, 16 May 2000 00:12:25 +1000
Martijn van Oosterhout <kleptog@cupid.suninternet.com>
Re: Dumping and reloading stuff in 6.5.3
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

Mon, 15 May 2000 10:15:53 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Dumping and reloading stuff in 6.5.3 
> 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

Mon, 15 May 2000 14:32:45 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Dumping and reloading stuff in 6.5.3