Thread: Initdb failure with PG 7.1.3 on RH 7.1...
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. After building the PG from the source tarball, both 'make check' and the actual install fail with the same symptoms. I have been all over this. Permissions are set correctly as far as I can see--doing the install as user postgres. I have gotten postgres to install once in a while on this system in all my attempts, but cannot reliably get it to work. I am installing from sources since I need long field names have have to change postgres_ext.h to accept longer field names. Although the install fails with the stock values. No compile errors of course. Anybody got a clue? I'm fresh out... Thanks, -paul Here is the console output with debug on in initdb: [postgres@redtop postgres]$ /usr/local/pgsql/bin/initdb -d -D -n /usr/local/pgsql/data Running with debug mode on. Initdb variables: PGDATA=/usr/local/pgsql/data datadir=/usr/local/pgsql/share PGPATH=/usr/local/pgsql/bin TEMPFILE=/tmp/initdb.8184 MULTIBYTE= MULTIBYTEID=0 POSTGRES_SUPERUSERNAME=postgres POSTGRES_SUPERUSERID=504 TEMPLATE1_BKI=/usr/local/pgsql/share/template1.bki GLOBAL_BKI=/usr/local/pgsql/share/global.bki TEMPLATE1_DESCR=/usr/local/pgsql/share/template1.description GLOBAL_DESCR=/usr/local/pgsql/share/global.description POSTGRESQL_CONF_SAMPLE=/usr/local/pgsql/share/postgresql.conf.sample PG_HBA_SAMPLE=/usr/local/pgsql/share/pg_hba.conf.sample PG_IDENT_SAMPLE=/usr/local/pgsql/share/pg_ident.conf.sample This database system will be initialized with username "postgres". This user will own all the data files and must also own the server process. Fixing permissions on existing directory /usr/local/pgsql/data Creating directory /usr/local/pgsql/data/base Creating directory /usr/local/pgsql/data/global Creating directory /usr/local/pgsql/data/pg_xlog Creating template1 database in /usr/local/pgsql/data/base/1 Running: /usr/local/pgsql/bin/postgres -boot -x1 -C -F -D/usr/local/pgsql/data -d template1 DEBUG: database system was shut down at 2001-11-30 07:43:24 EST DEBUG: CheckPoint record at (0, 8) DEBUG: Redo record at (0, 8); Undo record at (0, 8); Shutdown TRUE DEBUG: NextTransactionId: 514; NextOid: 16384 DEBUG: database system is in production state Creating global relations in /usr/local/pgsql/data/global Running: /usr/local/pgsql/bin/postgres -boot -C -F -D/usr/local/pgsql/data -d template1 DEBUG: database system was shut down at 2001-11-30 07:43:29 EST DEBUG: CheckPoint record at (0, 72) DEBUG: Redo record at (0, 72); Undo record at (0, 0); Shutdown TRUE DEBUG: NextTransactionId: 514; NextOid: 16384 DEBUG: database system is in production state Initializing pg_shadow. initdb failed. Removing temp file /tmp/initdb.8184. 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)
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