Re: 7.3.4 vacuum/analyze error - Mailing list pgsql-general

From Ed L.
Subject Re: 7.3.4 vacuum/analyze error
Date
Msg-id 200409292052.57804.pgsql@bluepolka.net
Whole thread Raw
In response to Re: 7.3.4 vacuum/analyze error  ("Ed L." <pgsql@bluepolka.net>)
List pgsql-general
On Wednesday September 29 2004 8:33, Ed L. wrote:
> On Wednesday September 29 2004 5:17, Tom Lane wrote:
> > "Ed L." <pgsql@bluepolka.net> writes:
> > > I'm getting a slew of these repeatable errors when running ANALYZE
> > > and/or VACUUM ANALYZE (from an autovacuum process) against a
> > > 7.3.4 cluster on HP-UX B.11.00:
> > >
> > > 2004-09-29 18:14:53.621 [520]    ERROR:  Memory exhausted in
> > > AllocSetAlloc(1189)
> > >
> > > Analyze: 132263832 total in 27 blocks; 2984 free (35 chunks);
> > > 132260848 used
> >
> > Either increase your per-process memory limit, or reduce the statistics
> > targets for this table ...
>
> What am I missing?
>
> $ ulimit -a
> memory(kbytes)       unlimited
>
> $ psql -c "select name, setting from pg_settings" | egrep stats_
>  stats_block_level              | off
>  stats_command_string           | off
>  stats_reset_on_server_start    | on
>  stats_row_level                | off
>  stats_start_collector          | on
>
> $ psql -c "analyze audit"
> ERROR:  Memory exhausted in AllocSetAlloc(1189)

We actually count on those stats (stats_row_level?) in order to effectively
autovacuum based on real changes, so turning them off would not be good.
Is this a bug fixed in a later versions?  What might be triggering this?
The only thing I see in common is that all the tables are frequently
updated...

Ed


pgsql-general by date:

Previous
From: "Ed L."
Date:
Subject: Re: 7.3.4 vacuum/analyze error
Next
From: Tom Lane
Date:
Subject: Re: 7.3.4 vacuum/analyze error