Обсуждение: FATAL: cache lookup failed for function 1003
Is this the right list for this? I'm off the 'net atm and can't easily check. I'm running on self-built RHEL 4. I built from cvs this morning, and get the above error. Running grep over the source doesn't show anything helpful to me. The initdb command (sans --auth) works for psql (PostgreSQL) 7.4.6 so I'm guessing I'm close. What might be the problem? + rm -rf /home/pgtest/postgres/data + mkdir -p --mode=0700 /home/pgtest/postgres/data + initdb --auth=trust FATAL: cache lookup failed for function 1003 child process exited with exit code 1 initdb: removing contents of data directory "/home/pgtest/postgres/data" The files belonging to this database system will be owned by user "pgtest". This user must also own the server process. The database cluster will be initialized with locale en_AU.UTF-8. The default database encoding has accordingly been set to UTF8. fixing permissions on existing directory /home/pgtest/postgres/data ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers/max_fsm_pages ... 24MB/153600 creating configuration files ... ok creating template1 database in /home/pgtest/postgres/data/base/1 ... real 0m1.088s user 0m0.530s sys 0m0.523s [pgtest@bilby ~]$
John Summerfield wrote: > Is this the right list for this? I'm off the 'net atm and can't easily > check. > > I'm running on self-built RHEL 4. > > I built from cvs this morning, and get the above error. Running grep > over the source doesn't show anything helpful to me. > The initdb command (sans --auth) works for psql (PostgreSQL) 7.4.6 so > I'm guessing I'm close. > > What might be the problem? Try doing a "make distclean" and recompile. -- Alvaro Herrera http://www.advogato.org/person/alvherre "Hay dos momentos en la vida de un hombre en los que no debería especular: cuando puede permitírselo y cuando no puede" (Mark Twain)
Alvaro Herrera wrote: > John Summerfield wrote: > >>Is this the right list for this? I'm off the 'net atm and can't easily >>check. >> >>I'm running on self-built RHEL 4. >> >>I built from cvs this morning, and get the above error. Running grep >>over the source doesn't show anything helpful to me. >>The initdb command (sans --auth) works for psql (PostgreSQL) 7.4.6 so >>I'm guessing I'm close. >> >>What might be the problem? > > > Try doing a "make distclean" and recompile. Thanks Alvaro That (combined with another cvs update) cleared the problem. Should the distclean be necessary?
John Summerfield wrote: > Alvaro Herrera wrote: > >John Summerfield wrote: > > > >>Is this the right list for this? I'm off the 'net atm and can't easily > >>check. > >> > >>I'm running on self-built RHEL 4. > >> > >>I built from cvs this morning, and get the above error. Running grep > >>over the source doesn't show anything helpful to me. > >>The initdb command (sans --auth) works for psql (PostgreSQL) 7.4.6 so > >>I'm guessing I'm close. > >> > >>What might be the problem? > > > > > >Try doing a "make distclean" and recompile. > > Thanks Alvaro > > > That (combined with another cvs update) cleared the problem. Should the > distclean be necessary? I use configure --enable-depend which removes the requirement. Otherwise, yes, you need to do a make distclean everytime you do an update. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
John Summerfield <postgres@herakles.homelinux.org> writes:
> That (combined with another cvs update) cleared the problem. Should the
> distclean be necessary?
Yes, unless you configured with --enable-depend during your previous
build (and I wouldn't necessarily swear that --enable-depend catches
every possible dependency).
When in doubt --- especially if your build fails but the buildfarm seems
happy --- do a distclean & rebuild before investing any intellectual
effort in figuring out the problem.
My own practice, developed after a couple of unpleasant episodes of this
sort, is to make distclean before any cvs update. Machine cycles are
cheap, my time isn't. I've found that I can generally overlap the
rebuild time with useful work, or at least mail-reading ...
regards, tom lane