Erik Jones <[EMAIL PROTECTED]> 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?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
