Have you done an initdb. Just a thought.
I'd do: delete/move old pgsql tree including data/bin/include/lib directories make distclean - because there could
stillbe some date problems (i.e.
gram.c) make make install initdb start postmaster run regression try \d on the regression database
Sorry if you already said that you ran initdb.-DEJ
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Wednesday, March 24, 1999 10:16 AM
> To: James Thompson
> Cc: pgsql-hackers@postgreSQL.org
> Subject: Re: [HACKERS] backend unstable, \d broken, groups broken was
> CVS 3-22-99 \d broken?
>
>
> James Thompson <jamest@math.ksu.edu> writes:
> > [ many things very broken despite full rebuild ]
>
> Sounds like you've hit some kind of platform-specific breakage, then.
>
> I'd suggest chasing the \d failure, simply because that's apparently
> the easiest thing to reproduce. Look at the source code for psql.c,
> and try issuing by hand the same queries it uses to obtain the system
> table info for \d. Use a debugger to look at the data coming back
> from the backend during \d --- in other words, is the lossage in psql
> or in the backend? Most likely it's the backend but you ought to make
> sure.
>
> I'm not enough of a backend guru to suggest where to look for
> the fault
> inside the backend... anyone?
>
> > I've noticed the backend is not stable. I think it has
> something to do
> > with permissions/passwords. I don't have exact details but
> if I change
> > passwords, create users, or do a large quantity of grants
> the backend
> > seems to die when the db superuser exits psql. At least
> the next login
> > fails due to no backend process running.
>
> You mean no postmaster process running. Is there a corefile? (The
> postmaster would drop core in the directory you started it in, IIRC;
> or it might be the top /usr/local/pgsql/data/ directory.) If so,
> what backtrace do you get from it?
>
> regards, tom lane
>
