Re: More 8.2 client issues (Was: [Slow dump?)

[Erik Jones <erik(at)myemma(dot)com>]

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