I have this weird problem where pgadmin3 shows empty schema's (tables(0), views(0), etc) while they are not empty at all. I upgraded to the 1.2.0-0.0+beta2.0 debian package, but the problem persists.
Refreshing the schema causes the schema to disappear from the pgadmin3 tree. This is the query I see executed when doing the refresh:
SELECT CASE WHEN nspname LIKE 'pg\_temp\_%%' THEN 1
WHEN nsp.oid<17140 OR nspname like 'pg\_%' THEN 0
ELSE 2 END as nsptyp,
nsp.nspname, nsp.oid, pg_get_userbyid(nspowner) AS namespaceowner, nspacl, description, has_schema_privilege(nsp.oid, 'CREATE')
FROM pg_namespace nsp
LEFT OUTER JOIN pg_description des ON des.objoid=nsp.oid
WHERE nsp.oid=2147483647::oid
ORDER BY 1, nspname
I examined pg_namespace and the oid of the schema actually is 2518196330. No wonder pgadmin3 thinks it's empty.
2147483647 is 0x7fffffff, i.e. LONG_MAX. Apparently, some function is cutting down the real oid value, which is 0x9618a06a.
Digging into the sources, I found two places where oids are converted using atol, which might be the offending function. I changed both to strtoul, and committed the changes to cvs.
Please check it (misc.cpp and pgSet.cpp affected) from source if possible or try Beta3, which we're be rolling quite soon an give us feedback because I don't have a test case.
Some remark:
Apparently your database consumes enormous amounts of oids, you're more than half way to a oid wrap which might cause undesired effects (duplicate oids). Your tables are probably all created WITH OIDS, which is still the default. You might consider dropping the oid columns, if you don't need them.
Regards, Andreas
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
