Hi all,
there appears to be some problems with 64-bit-cleaness of
v7.0. I've got it the identical operations working fine on both Linux/x86
and OpenBSD/x86, but it dies on my Alpha box.
Alpha specs: AS200 4/166 w/72MB running Debian Linux 2.1 with kernel 2.2.15
Extra ./configure options: none
Compiler used: egcs-1.1.2
Libraries linked to:
libc6.1 2.0.7.19981211 GNU C Library: shared libraries
libncurses4 4.2-3 Shared libraries for terminal handling
libreadlineg2 2.1-12 GNU readline and history libraries
Admittedly, some of these are getting ancient, but due to it working on
the x86 Linux box with roughly the same library versions, I don't think
that's the problem.
Problem description:
--------------------
"\d tablename", "\do", "\df" and perhaps other commands inside psql
produce the following error: "getattproperties: no attribute tuple XXXX -2"
The numeric XXXX value is different depending on the command issued, but
is always the same value for the same command. The problem has continued
even after another initdb.
It doesn't seem to be related to user table layouts - something to do with
OID processing according to my fiddling below.
Example:
db=> \d
List of relations
Name | Type | Owner
----------------+----------+--------
author | table | planet
db=> \d author
********* QUERY *********
SELECT relhasindex, relkind, relchecks, reltriggers, relhasrules
FROM pg_class WHERE relname='author'
*************************
********* QUERY *********
SELECT a.attname, t.typname, a.attlen, a.atttypmod, a.attnotnull, a.atthasdef, a
.attnum
FROM pg_class c, pg_attribute a, pg_type t
WHERE c.relname = 'author'
AND a.attnum > 0 AND a.attrelid = c.oid AND a.atttypid = t.oid
ORDER BY a.attnum
*************************
ERROR: getattproperties: no attribute tuple 1259 -2
db=> select oid from pg_class where oid = 1259;
ERROR: getattproperties: no attribute tuple 1259 -2
db=> \do
ERROR: getattproperties: no attribute tuple 1255 -2
db=> \df
ERROR: getattproperties: no attribute tuple 1247 -2
I have no idea where to start with tracking this down, or I'd be off
quietly bugfinding :-)
Hope this helps someone find and fix the problem - it means pg_dump won't
work, which is far more serious than not being able to describe a table...
Regards,
Nic.
-- Nic Bellamy <[email protected]>
Director, Bellamy Consulting Ltd.