Initdb failure with PG 7.1.3 on RH 7.1...

Paul Stavrides <pstav123@adelie.net> writes:

Here is a wierd one...

Initdb is failing most of the time on RH 7.1. Postgresql ver 7.1.3 and 7.1.2.

Post your error messages and we might be able to help.

-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863

Paul Stavrides <pstav123@adelie.net> writes:

Initdb is failing most of the time on RH 7.1.

Very strange, considering that lots of other people build successfully
on the same platform. I've got to think there is something odd about
your local setup.

... I am installing from sources since I need long
field names have have to change postgres_ext.h to accept longer field
names.

You did edit NAMEDATALEN *before* you compiled anything, right? After
you've changed it, you'd probably need a "make clean" before rebuilding.
Also, what did you set it to?

If I turn on logging in postgres, I get the following log file:

DEBUG: database system was shut down at 2001-11-29 17:02:43 EST
DEBUG: CheckPoint record at (0, 136)
DEBUG: Redo record at (0, 136); Undo record at (0, 0); Shutdown TRUE
DEBUG: NextTransactionId: 514; NextOid: 16384
DEBUG: database system is in production state
DEBUG: connection: host=(null) user=postgres database=template1
DEBUG: InitPostgres
FATAL 1: cannot open /usr/local/pgsql/data/global/1262: No such file or
directory <-- ?? !
FindExec: found "/usr/local/pgsql/bin/postgres" using argv[0]
DEBUG: proc_exit(1)
DEBUG: shmem_exit(1)
DEBUG: shutting down
DEBUG: database system is shut down
DEBUG: exit(1)

Most peculiar. .../1262 would be pg_database, which certainly ought to
exist. If you run initdb with --noclean, is that file present after the
failure? Permissions and so forth look reasonable? What's its size?

regards, tom lane

Tom Lane wrote:

Paul Stavrides <pstav123@adelie.net> writes:

Initdb is failing most of the time on RH 7.1.

Very strange, considering that lots of other people build successfully
on the same platform. I've got to think there is something odd about
your local setup.

Yes, I would think so. Inconsistant too. I got it to run once with a
switch back to 7.3.1 from 7.3.2. I will have to try on another machine.
I had the rpm's install on my laptop here, but I thought that I
removed any files that the rpms might have dropped in my path. I am
specifying all paths completely. Maybe some paths are not quite kosher
for the postgres user....

You did edit NAMEDATALEN *before* you compiled anything, right? After
you've changed it, you'd probably need a "make clean" before rebuilding.
Also, what did you set it to?

Oh yea. I think I set it to 100. I have even resorted to 'make
distclean' and a reconfigure in between trials...

Most peculiar. .../1262 would be pg_database, which certainly ought to
exist. If you run initdb with --noclean, is that file present after the
failure? Permissions and so forth look reasonable? What's its size?

Yes, I know, the -n switch. No, 1262 never gets created as far as I can
tell. I am going to have to get much deeper into this, I'm afraid.

Thanks,

-paul

Paul Stavrides <pstav123@adelie.net> writes:

Yes, I know, the -n switch. No, 1262 never gets created as far as I can
tell. I am going to have to get much deeper into this, I'm afraid.

How about the other files in $PGDATA/global? (Posting an ls -lR of
the post-failure $PGDATA might be helpful.)

pg_database should be created, and one entry put into it, as a result of
the first steps in the "Creating global relations" operation (the
postgres run that's reading global.bki). Correct contents of
$prefix/share/global.bki for 7.1 are exhibited below --- does yours look
the same?

regards, tom lane

# PostgreSQL 7.1
# 1 "/tmp/genbkitmp.c"
create bootstrap pg_database
(
datname = name ,
datdba = int4 ,
encoding = int4 ,
datistemplate = bool ,
datallowconn = bool ,
datlastsysoid = oid ,
datpath = text
)
insert OID = 1 ( template1 PGUID ENCODING t t 0 "" )
close pg_database
create bootstrap pg_variable
(
varfoo = oid
)
close pg_variable
create bootstrap pg_shadow
(
usename = name ,
usesysid = int4 ,
usecreatedb = bool ,
usetrace = bool ,
usesuper = bool ,
usecatupd = bool ,
passwd = text ,
valuntil = int4
)
insert OID = 0 ( "POSTGRES" PGUID t t t t _null_ _null_ )
close pg_shadow
create bootstrap pg_group
(
groname = name ,
grosysid = int4 ,
grolist = int4[]
)
close pg_group
create bootstrap pg_log
(
logfoo = oid
)
close pg_log

Tom Lane wrote:

How about the other files in $PGDATA/global? (Posting an ls -lR of
the post-failure $PGDATA might be helpful.)

pg_database should be created, and one entry put into it, as a result of
the first steps in the "Creating global relations" operation (the
postgres run that's reading global.bki). Correct contents of
$prefix/share/global.bki for 7.1 are exhibited below --- does yours look
the same.

No, looks like this is the cause. My $prefix/share/global.bki is only
17 bytes long and has only the header line:

# PostgreSQL 7.1

I guess I need to figure out how/when this is generated in the build
process.

-paul

The ll -R of $PGDATA is short:

[postgres@redtop pgsql]$ ll -R data
data:
total 32
drwx------ 3 postgres postgres 4096 Nov 30 12:11 base
drwx------ 2 postgres postgres 4096 Nov 30 12:11 global
-rw------- 1 postgres postgres 7399 Nov 30 12:11 pg_hba.conf
-rw------- 1 postgres postgres 1118 Nov 30 12:11 pg_ident.conf
-rw------- 1 postgres postgres 4 Nov 30 12:11 PG_VERSION
drwx------ 2 postgres postgres 4096 Nov 30 12:11 pg_xlog
-rw------- 1 postgres postgres 3137 Nov 30 12:11 postgresql.conf

data/base:
total 4
drwx------ 2 postgres postgres 4096 Nov 30 12:11 1

data/base/1:
total 4
-rw------- 1 postgres postgres 4 Nov 30 12:11 PG_VERSION

data/global:
total 8
-rw------- 1 postgres postgres 8192 Nov 30 12:11 pg_control

data/pg_xlog:
total 16404
-rw------- 1 postgres postgres 16777216 Nov 30 12:11 0000000000000000

My global.bki in $prefix/share/ is exactly the same as you said it shoud
be but the

Paul Stavrides <pstav123@adelie.net> writes:

No, looks like this is the cause. My $prefix/share/global.bki is only
17 bytes long and has only the header line:

# PostgreSQL 7.1

Ah-hah. We've seen some prior reports of portability problems in the
sed commands used by src/backend/catalog/genbki.sh, which is the script
that builds those files. But the last fix in that area was pre-7.1
release. Maybe you have a broken sed or awk installed?

regards, tom lane

Tom Lane wrote:

Ah-hah. We've seen some prior reports of portability problems in the
sed commands used by src/backend/catalog/genbki.sh, which is the script
that builds those files. But the last fix in that area was pre-7.1
release. Maybe you have a broken sed or awk installed?

regards, tom lane

Well, that might be. I will have a look. For the record,

[pstav@redtop postgresql-7.1.3]$ sed -V
GNU sed version 3.02

[pstav@redtop postgresql-7.1.3]$ awk --version
GNU Awk 3.0.6

Thanks,

-paul

Tom Lane wrote:

Paul Stavrides <pstav123@adelie.net> writes:

No, looks like this is the cause. My $prefix/share/global.bki is only
17 bytes long and has only the header line:

# PostgreSQL 7.1

Ah-hah. We've seen some prior reports of portability problems in the
sed commands used by src/backend/catalog/genbki.sh, which is the script
that builds those files. But the last fix in that area was pre-7.1
release. Maybe you have a broken sed or awk installed?

regards, tom lane

Tom,

Hmmm, checked the sed and awk and they are up to date.... I'm not an
expert, but it looks like the Makefile in ../src/backend/catalog/ isn't
reporting sed's exit status up the chain. So I lied about there being
no build errors.... to whit:

/usr/bin/ld -r -o SUBSYS.o catalog.o heap.o index.o indexing.o aclchk.o
pg_aggregate.o pg_largeobject.o pg_operator.o pg_proc.o pg_type.o
CPP='gcc -E' AWK='gawk' /bin/sh genbki.sh -o global
-I../../../src/include ../../../src/include/catalog/pg_database.h
../../../src/include/catalog/pg_variable.
h ../../../src/include/catalog/pg_shadow.h
../../../src/include/catalog/pg_group.h
../../../src/include/catalog/pg_log.h --set-version=7.1.3
sed: -e expression #9, char 25: Unterminated `s' command
CPP='gcc -E' AWK='gawk' ....{snip}...
set-version=7.1.3
sed: -e expression #9, char 25: Unterminated `s' command

The build still proceeds, even with these errors. They go by in a flash
and the executable is still created. I have to see what I did to make
sed go nuts.

Thanks for your time. I will report what I find out to finish the thread...

Cheers,

-paul

Tom Lane wrote:

Ah-hah.

Ok we're fixed.

My crime was using a 'c' comment to keep track of the changes I made in
the postgress_ext.h file:

DON'T DO THIS:

/*
* NAMEDATALEN is the max length for system identifiers (e.g. table names,
* attribute names, function names, etc.)
*
* NOTE that databases with different NAMEDATALEN's cannot interoperate!
*/
/* #define NAMEDATALEN 32 */

#define NAMEDATALEN 100

#endif

The post-processing of this file in genbki.sh will fail and not stop the
build process. I am not an sh/sed naive but I think one of the sed
commands needs an if <clause> fi || exit type mod to keep this happening
in the future.

It may be enough to document that it can happen.

Thanks for your help,

-paul

Paul Stavrides <pstav123@adelie.net> writes:

My crime was using a 'c' comment to keep track of the changes I made in
the postgress_ext.h file:

Ah so. The genbki script needs to be more careful about what it will
match --- #define with a comment marker in front of it shouldn't match.

The post-processing of this file in genbki.sh will fail and not stop the
build process. I am not an sh/sed naive but I think one of the sed
commands needs an if <clause> fi || exit type mod to keep this happening
in the future.

Yeah, some more error checking is needed there too. I'll see what I can
do.

regards, tom lane

If I remember a previous discussion correctly, the
problem is not having a "bad" sed, but a
"too-up-to-date" one.  Someone got carried away with
escaping, which resulted in some "\n" combination(s)
appearing in regular expressions used by sed.  Not a
problem with most seds, which interpret that as just
"n", but GNU sed interprets "\n" as a newline
character.  A small change to the code should see you
clear.
--- Paul Stavrides <pstav123@adelie.net> wrote:

Tom Lane wrote:

Paul Stavrides <pstav123@adelie.net> writes:

No, looks like this is the cause. My

$prefix/share/global.bki is only

17 bytes long and has only the header line:

# PostgreSQL 7.1

Ah-hah. We've seen some prior reports of

portability problems in the

sed commands used by src/backend/catalog/genbki.sh,

which is the script

that builds those files. But the last fix in that

area was pre-7.1

release. Maybe you have a broken sed or awk

installed?

regards, tom lane

Tom,

Hmmm, checked the sed and awk and they are up to
date.... I'm not an
expert, but it looks like the Makefile in
../src/backend/catalog/ isn't
reporting sed's exit status up the chain. So I lied
about there being
no build errors.... to whit:

/usr/bin/ld -r -o SUBSYS.o catalog.o heap.o index.o
indexing.o aclchk.o
pg_aggregate.o pg_largeobject.o pg_operator.o
pg_proc.o pg_type.o
CPP='gcc -E' AWK='gawk' /bin/sh genbki.sh -o global

-I../../../src/include
../../../src/include/catalog/pg_database.h
../../../src/include/catalog/pg_variable.
h ../../../src/include/catalog/pg_shadow.h
../../../src/include/catalog/pg_group.h
../../../src/include/catalog/pg_log.h
--set-version=7.1.3
sed: -e expression #9, char 25: Unterminated `s'
command
CPP='gcc -E' AWK='gawk' ....{snip}...
set-version=7.1.3
sed: -e expression #9, char 25: Unterminated `s'
command

The build still proceeds, even with these errors.
They go by in a flash
and the executable is still created. I have to see
what I did to make
sed go nuts.

Thanks for your time. I will report what I find out
to finish the thread...

Cheers,

-paul

---------------------------(end of
broadcast)---------------------------
TIP 2: you can get off all lists at once with the
unregister command
(send "unregister YourEmailAddressHere" to

majordomo@postgresql.org)

__________________________________________________
Do You Yahoo!?
Buy the perfect holiday gifts at Yahoo! Shopping.
http://shopping.yahoo.com