Thread: CVS 3-22-99 \d broken?

This afternoon CVS download.

Table created via
create table customer (       uid                     varchar(30) primary key,       id
varchar(30)unique,       name_first              varchar(30) not null,       name_middle             varchar(30),
name_last              varchar(30) not null,       company                 varchar(80),       address1
varchar(50)not null,       address2                varchar(50),       city                    varchar(30) not null,
 state                   char(2),       country                 varchar(80),       zip                     int4,
phone_work             varchar(12),       phone_home              varchar(12),       phone_fax
varchar(12),      email                   varchar(30),       date_entered            date        not null,
billing_terms          varchar(15) not null,       confirmation_method     varchar(10) );
 



\d reports

obe=> \d customer


Table    = customer
+----------------------------------+----------------------------------+-------+
|              Field               |              Type                |Length|
+----------------------------------+----------------------------------+-------+
| uid                              | varchar() not null               |30 |
| id                               | varchar()                        |30 |
| name_first                       | varchar() not null               |30 |
| name_middle                      | varchar()                        |30 |
| name_last                        | varchar() not null               |30 |
| company                          | varchar()                        |80 |
| address1                         | varchar() not null               |50 |
| address2                         | varchar()                        |50 |
| city                             | varchar() not null               |30 |
| date_entered                     | date not null                    |4 |
+----------------------------------+----------------------------------+-------+
Indices:  customer_id_key         customer_pkey



But select * shows the columns exist

obe=> select * from customer;

uid|id|name_first|name_middle|name_last|company|address1|address2|city|state|country|zip|phone_work|phone_home|phone_fax|

---+--+----------+-----------+---------+-------+--------+--------+----+-----+-------+---+----------+----------+---------+
email|date_entered|billing_terms|confirmation_method
-----+------------+-------------+-------------------
(0 rows)


I deleted my data dir and started over with initdb with the same results.
All of the tables where created with a script that was not generated by
pgdump.

System tables and views seem to be affected as well

->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
James Thompson    138 Cardwell Hall  Manhattan, Ks   66506    785-532-0561 
Kansas State University                          Department of Mathematics
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<

James Thompson <jamest@math.ksu.edu> writes:
>  [ psql's \d not working right ]

Hmm, it works OK for me on sources from Sunday --- and a quick check
shows no interesting changes since then.  Either you've found a
platform-specific bug, or you didn't rebuild correctly after cvs update.

Doing a partial rebuild after an update is risky because the Postgres
makefiles are sloppy about declaring all dependencies.  (You can
improve matters by doing "make depend", if you are using gcc, but I'm
not sure that will solve the problem entirely.)  I usually play the
game conservatively by doing make distclean and a full rebuild after
an update, unless I see that the changes were very localized.
        regards, tom lane

On Tue, 23 Mar 1999, Tom Lane wrote:

> James Thompson <jamest@math.ksu.edu> writes:
> >  [ psql's \d not working right ]
> 
> Hmm, it works OK for me on sources from Sunday --- and a quick check
> shows no interesting changes since then.  Either you've found a
> platform-specific bug, or you didn't rebuild correctly after cvs update.
>

Moved my old copy of the pgsql tree and checked out the entire thing
yestereday afternoon to insure a fresh copy.  Used all defaults

./configure 
make 
make install

\d still does not display complete table listings.  Everything (select,
insert, update, delete) seems to work though.  Regression test pass well
enough (error messages different, a few rounding errors, etc)

I have noticed a lot of little oddities.

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.  I must remove the /tmp/.s.* file
and restart the backend.  (Is there an error I can look at somewhere?)

The psql command  create user jamest;
does not work.  I must use createuser from the shell.

Groups do not work.  I can create the group using the insert command in 
the manual, I can add people to the group.  But those people cannot select
from the tables, some type of group 0 error occurs.

I apologize for being vague, my net connection for home was hideous last
night so I'm doing this from memory at work.

I've tried this on a "stock" RedHat 5.2 system (gcc and friends are the
RPMs that came with the system).  A modified RedHat 5.1 system with latest
gcc 2.7.x series compiler.  Both behave in the exact same mannor.

My previous CVS code from about a week ago didn't have the \d problem.  I
can't say on the other problems as I started using these features after my
recent cvs update.

Any ideas on where I should look for clues as to what has went wrong?

TIA

->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
James Thompson    138 Cardwell Hall  Manhattan, Ks   66506    785-532-0561 
Kansas State University                          Department of Mathematics
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<

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