[BUGS] BUG #5283: Missing "base/1/ON" file during initdb
The following bug has been logged online: Bug reference: 5283 Logged by: Robert Treat Email address: xzi...@users.sourceforge.net PostgreSQL version: 8.4.2 Operating system: Slackware Linux 2.6.23.14-grsec Description:Missing "base/1/ON" file during initdb Details: Trying to install 8.4.2 on Linux 2.6.23.14-grsec from source tarball configure line is this: ./configure '--prefix=/usr/local/pgsql-8.4.2' '--enable-debug' '--enable-depend' '--enable-cassert' '--enable-thread-safety' '--with-libxml' '--disable-largefile' I added --disable-largefile to configure after getting the following error during "make install" access/transam/xlog.o: In function `XLogFileClose': /usr/local/src/postgresql-8.4.2/src/backend/access/transam/xlog.c:2610: undefined reference to `posix_fadvise64' storage/file/fd.o: In function `FilePrefetch': /usr/local/src/postgresql-8.4.2/src/backend/storage/file/fd.c:1096: undefined reference to `posix_fadvise64' collect2: ld returned 1 exit status make[2]: *** [postgres] Error 1 With largefile support disabled, make install worked fine, but now I am getting the following error during initdb. r...@phppgadmin:/usr/local/src/postgresql-8.4.2/src# sudo -u postgres /usr/local/pgsql-8.4.2/bin/initdb -D /usr/local/pgsql/data/84/ The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale C. The default database encoding has accordingly been set to SQL_ASCII. The default text search configuration will be set to "english". fixing permissions on existing directory /usr/local/pgsql/data/84 ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers ... 28MB creating configuration files ... ok creating template1 database in /usr/local/pgsql/data/84/base/1 ... ok initializing pg_authid ... ok initializing dependencies ... ok creating system views ... ok loading system objects' descriptions ... ok creating conversions ... ok creating dictionaries ... ok setting privileges on built-in objects ... ok creating information schema ... ok vacuuming database template1 ... ok copying template1 to template0 ... FATAL: could not stat file "base/1/ON": No such file or directory STATEMENT: CREATE DATABASE template0; child process exited with exit code 1 initdb: removing contents of data directory "/usr/local/pgsql/data/84" I've installed 7.old -> 8.3 on this machine before, so this seems like something new in 8.4. Any help is appreciated. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5283: Missing "base/1/ON" file during initdb
"Robert Treat" writes: > I added --disable-largefile to configure after getting the following error > during "make install" > access/transam/xlog.o: In function `XLogFileClose': > /usr/local/src/postgresql-8.4.2/src/backend/access/transam/xlog.c:2610: > undefined reference to `posix_fadvise64' Hmm, that looks like platform breakage that you ought to report to Slackware. We could probably make the configure test for posix_fadvise a little tighter, but not having a largefile variant of it doesn't seem like an expected situation. > copying template1 to template0 ... FATAL: could not stat file "base/1/ON": > No such file or directory Did you "make distclean" to be sure you had a clean start after changing the largefile setting? I'm not sure what all that affects, but a build that's only partially "largefile" would probably have some weird issues. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5283: Missing "base/1/ON" file during initdb
I wrote: > "Robert Treat" writes: >> I added --disable-largefile to configure after getting the following error >> during "make install" >> access/transam/xlog.o: In function `XLogFileClose': >> /usr/local/src/postgresql-8.4.2/src/backend/access/transam/xlog.c:2610: >> undefined reference to `posix_fadvise64' > Hmm, that looks like platform breakage that you ought to report to > Slackware. We could probably make the configure test for posix_fadvise > a little tighter, but not having a largefile variant of it doesn't seem > like an expected situation. I've committed some changes that I think should cause configure to decide that posix_fadvise() isn't available in situations like this. Would you be willing to test that? >> copying template1 to template0 ... FATAL: could not stat file "base/1/ON": >> No such file or directory This bit still seems pretty weird ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5283: Missing "base/1/ON" file during initdb
On Saturday 16 January 2010 14:02:16 Tom Lane wrote: > "Robert Treat" writes: > > I added --disable-largefile to configure after getting the following > > error during "make install" > > > > access/transam/xlog.o: In function `XLogFileClose': > > /usr/local/src/postgresql-8.4.2/src/backend/access/transam/xlog.c:2610: > > undefined reference to `posix_fadvise64' > > Hmm, that looks like platform breakage that you ought to report to > Slackware. We could probably make the configure test for posix_fadvise > a little tighter, but not having a largefile variant of it doesn't seem > like an expected situation. > Well, the box is old, and probably not as patched as it should be, so that probably doesn't help. > > copying template1 to template0 ... FATAL: could not stat file > > "base/1/ON": No such file or directory > > Did you "make distclean" to be sure you had a clean start after changing > the largefile setting? I'm not sure what all that affects, but a build > that's only partially "largefile" would probably have some weird issues. > Blech. Didn't think about that, as I wasn't building from $scm, but I just wiped my source tree away, blew the tarball back open, and did the whole dance again, and now initdb works fine, so yes, looks like some leftovers from a previous configure/make attempt before disabling fadvise. Nice catch, sorry for the noise. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
