Re: requested shared memory size overflows size_t - Mailing list pgsql-performance

From Jim Montgomery
Subject Re: requested shared memory size overflows size_t
Date
Msg-id SNT123-W49BF46CDDFB62AD8A15444A7C70@phx.gbl
Whole thread Raw
In response to Re: requested shared memory size overflows size_t  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-performance
Remove me from your email traffic.
 
> Date: Thu, 24 Jun 2010 23:05:06 -0400
> Subject: Re: [PERFORM] requested shared memory size overflows size_t
> From: robertmhaas@gmail.com
> To: alvherre@commandprompt.com
> CC: craig_james@emolecules.com; pgsql-performance@postgresql.org
>
> On Thu, Jun 24, 2010 at 7:19 PM, Alvaro Herrera
> <alvherre@commandprompt.com> 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.
>
> Yeah - also, it would probably be good to call pg_relation_size on
> pg_class.oid rather than pg_class.relname, to avoid any chance of
> confusion over which objects are in which schema.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise Postgres Company
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance


Get a free e-mail account with Hotmail. Sign-up now.

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Occasional giant spikes in CPU load
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Occasional giant spikes in CPU load