Re: [HACKERS] backend unstable, \d broken, groups broken was CVS 3-22-99 \d broken?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: James Thompson <jamest(at)math(dot)ksu(dot)edu>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] backend unstable, \d broken, groups broken was CVS 3-22-99 \d broken?
Date: 1999-03-24 16:16:22
Message-ID: 26403.922292182@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

James Thompson <jamest(at)math(dot)ksu(dot)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

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-03-24 16:21:40 Re: [HACKERS] 64-bit hashjoins
Previous Message Jan Wieck 1999-03-24 16:02:50 Re: [HACKERS] PostgreSQL LOGO (was: Developers Globe (FINAL))