Re: System tables screwed up? (WAS requested shared memory size overflows size_t) - Mailing list pgsql-performance

From Alvaro Herrera
Subject Re: System tables screwed up? (WAS requested shared memory size overflows size_t)
Date
Msg-id 1277423407-sup-289@alvh.no-ip.org
Whole thread Raw
In response to Re: System tables screwed up? (WAS requested shared memory size overflows size_t)  (Craig James <craig_james@emolecules.com>)
List pgsql-performance
Excerpts from Craig James's message of jue jun 24 19:24:44 -0400 2010:
> On 6/24/10 4:19 PM, Alvaro Herrera wrote:
> > Excerpts from Craig James's message of jue jun 24 19:03:00 -0400 2010:
> >
> >> select relname, pg_relation_size(relname) from pg_class
> >>           where pg_get_userbyid(relowner) = 'emol_warehouse_1'
> >>           and relname not like 'pg_%'
> >>           order by pg_relation_size(relname) desc;
> >> ERROR:  relation "rownum_temp" does not exist
> >>
> >> emol_warehouse_1=>  select relname from pg_class where relname = 'rownum_temp';
> >>          relname
> >> ----------------------
> >>    rownum_temp
> >> (1 row)
> >
> > What's the full row?  I'd just add a "WHERE relkind = 'r'" to the above
> > query anyway.
>
> Thanks, in fact that works.  But my concern is that these are system tables and system functions and yet they seem to
beconfused.  I've used this query dozens of times and never seen this behavior before.  It makes me really nervous... 

I think you're being bitten by lack of schema qualification.  Perhaps
you ought to pass pg_class.oid to pg_relation_size instead of relname.
What did you do to make pg_relation_size to work on type name?

Why is this a -performance question anyway?

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

pgsql-performance by date:

Previous
From: Craig James
Date:
Subject: Re: System tables screwed up? (WAS requested shared memory size overflows size_t)
Next
From: Craig James
Date:
Subject: Re: Occasional giant spikes in CPU load