Tom Lane wrote:
Erik Jones <erik@xxxxxxxxxx> writes:
...
sigaction(SIGPIPE, 0x08046E20, 0x08046E70) = 0
send(4, " Q\0\0\0E5 S E L E C T ".., 230, 0) = 230
<----------------------------------------------------------- Hang is
right here!
sigaction(SIGPIPE, 0x08046E20, 0x08046E70) = 0
pollsys(0x08046EE8, 1, 0x00000000, 0x00000000) (sleeping...)
pollsys(0x08046EE8, 1, 0x00000000, 0x00000000) = 1
recv(4, " T\0\0\0 P\003 o i d\0\0".., 16384, 0) = 140
...
Hmph. So it seems the delay really is on the server's end. Any chance
you could truss the connected backend process too and see what it's doing?
Actually ... before you do that, the first query for "\d pg_class"
should look like
SELECT c.oid,
n.nspname,
c.relname
FROM pg_catalog.pg_class c
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE c.relname ~ '^(pg_class)$'
AND pg_catalog.pg_table_is_visible(c.oid)
ORDER BY 2, 3;
I could see this taking an unreasonable amount of time if you had a huge
number of pg_class rows or a very long search_path --- is your database
at all out of the ordinary in those ways?
Well, running "select count(*) from pg_class;" returns 524699 rows and
our search path is the default. I'd also like to reiterate that \d
pg_class returns instantly when run from the 8.1.4 psql client connected
to the 8.2 db. How would I go about determining which backend server
process psql was attached to?
--
erik jones <erik@xxxxxxxxxx>
software development
emma(r)
