Tom Lane wrote:
> Erik Jones <erik@myemma.com> 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@myemma.com>
software development
emma(r)