Problems compiling version 7

Travis Bauer <trbauer@indiana.edu> writes:

I'm getting an odd error in the configure scripts:
. . .
checking for gzcat... (cached) /usr/local/gnu/bin/gzcat
checking for perl... (cached) perl
configure: error: Can't find method to convert from upper to lower case
with tr

I'm compiling this in Red Hat 6.0

Weird. Do you not have 'tr' in your PATH? You wouldn't be running with
some bizarre LOCALE setting, by any chance?

regards, tom lane

I have tr version 1.22 (GNU texutils). It is located in /usr/bin, and is
found by my login shell (cshrc).

How could I check the locale setting?

Thanks,

----------------------------------------------------------------
Travis Bauer | CS Grad Student | IU |www.cs.indiana.edu/~trbauer
----------------------------------------------------------------

On Tue, 9 May 2000, Tom Lane wrote:

Travis Bauer <trbauer@indiana.edu> writes:

I have tr version 1.22 (GNU texutils). It is located in /usr/bin, and is
found by my login shell (cshrc).

That was a weak theory, but worth checking ...

How could I check the locale setting?

echo $LOCALE I think --- someone who actually uses non-ASCII locales
would be a better reference than I. But the critical bit here is the
part of configure.in that's trying to find the right platform-specific
tr invocation:

dnl Check tr flags to convert from lower to upper case
TRSTRINGS="`echo ABCdef | $TR '[[a-z]]' '[[A-Z]]' 2>/dev/null | grep ABCDEF`"
TRCLASS="`echo ABCdef | $TR '[[:lower:]]' '[[:upper:]]' 2>/dev/null | grep ABCDEF`"

if test "$TRSTRINGS" = "ABCDEF"; then
TRARGS="'[[a-z]]' '[[A-Z]]'"
elif test "$TRCLASS" = "ABCDEF"; then
TRARGS="'[[:lower:]]' '[[:upper:]]'"
else
AC_MSG_ERROR("Can\'t find method to convert from upper to lower case with tr")
fi

(hmm ... the error message is exactly backwards from what's actually
being tested, isn't it? Minor point but...) Anyway, try these out
and see what's happening with your 'tr'. Note that the apparently
doubled square brackets are a quoting artifact of autoconf --- you
should actually test [a-z] and so on, not [[a-z]].

The really silly bit is that configure.in has several other invocations
of tr that pay no attention at all to the results so painfully extracted
(or mis-extracted) here. So it kinda looks to me like we could rip out
this test, hardwire the translation as
tr '[a-z]' '[A-Z]'
and be no worse off. Does anyone recall why this test is in there to
begin with?

regards, tom lane

Peter Eisentraut <e99re41@DoCS.UU.SE> writes:

On Tue, 9 May 2000, Tom Lane wrote:

dnl Check tr flags to convert from lower to upper case

Does anyone recall why this test is in there to begin with?

I don't see the results of this test being used anywhere at all, so I'd
say yank it. If your system doesn't support tr '[A-Z]' '[a-z]' the
configure script will fail to run anyway, as it uses this contruct
indiscriminately.

The results *are* used, in backend/utils/Gen_fmgrtab.sh.in (and
apparently nowhere else). But the data being processed there is just
builtin function names, so I'm at a loss why someone thought that it'd
be worth testing for a locale-specific variant of 'tr'. I agree, I'm
pretty strongly tempted to yank it.

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

regards, tom lane

I've found part of the problem. I put "echo $TR" right before the line
that is failing. $TR is set to "/usr/ucb/tr" during the
configuration. The directory ucb does not exist. If execute "which
tr" at the command line, I get "/usr/bin//tr." Why is $TR getting set to
/usr/ucb/tr?

By the way, I do not get this problem when compiling the last version of
Postgresql on this same machine. I'm in the processof upgrading. That
compile was fine.

Thanks,

----------------------------------------------------------------
Travis Bauer | CS Grad Student | IU |www.cs.indiana.edu/~trbauer
----------------------------------------------------------------

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

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

Peter Eisentraut <peter_e@gmx.net> writes:

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?)

Yup, or at least re-run config.status. I've griped that configure
writes far too many files myself. But I didn't have much luck
convincing the other developers that it's a bad idea to set things up
that way, rather than writing just a small number of config files.

We're going to have to deal with the problem though if we ever want
to be able to build in a separate directory tree...

regards, tom lane

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:

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:

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:

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