From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | george young <gry(at)ll(dot)mit(dot)edu> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Memory exhausted in AllocSetAlloc |
Date: | 2001-06-06 17:29:19 |
Message-ID: | Pine.BSF.4.21.0106061027450.16204-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
You probably should upgrade to 7.1.2. I think alot of
memory leaking conditions were fixed between 7.0 and 7.1.
On Wed, 6 Jun 2001, george young wrote:
> [Postgresql 7.0.3, intel Linux, 4 cpu, 2 GB RAM ]
>
> create table stepparams(step_proc text, name text, txt text, units text, step_ver int2, width int2,
> xpos int2, param_edit int2, xlevel int2, mandatory int2, primary key(step_proc));
>
> The table stepparams has 15799 rows, 387 distinct values of step_proc.
>
> For each value stepparams.step_proc e.g. 'foo', there should be a postgres table named "s_foo".
> I want to check this for consistancy, i.e. find any stepparams.step_proc that does not have a corresponding table.
>
> I thought this was a straight forward query:
> select distinct step_proc
> from stepparams sp
> where not exists (select * from pg_class where text(relname)= 's_' || sp.step_proc);
> but, after a while I get an error: FATAL 1: Memory exhausted in AllocSetAlloc()
> pqReadData() -- backend closed the channel unexpectedly.
> [indeed the backend had grown to 400MB, 173MB resident!]
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-06-06 17:49:19 | Re: Memory exhausted in AllocSetAlloc |
Previous Message | Stephan Szabo | 2001-06-06 17:27:00 | Re: Cascade constraint gone!!! |