| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
| Cc: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: 7.3.4 vacuum/analyze error |
| Date: | 2004-09-30 14:35:21 |
| Message-ID: | 16306.1096554921@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> On Wed, Sep 29, 2004 at 11:23:52PM -0600, Ed L. wrote:
>> On Wednesday September 29 2004 5:17, Tom Lane wrote:
>>> 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 ...
>>
>> Can you explain a little more of how you interpret the numbers above to draw
>> your conclusion?
> I just means that, from the operating system POV, there are 132263832
> bytes in use. The rest is Pg internal bookkeeping that doesn't help you
> any.
Well, the other potentially interesting deduction is that the failure
came during a request for a small additional amount of memory, viz 1189
bytes. Had the AllocSetAlloc call been requesting hundreds of megs,
my thoughts would have turned to corrupt data (specifically a broken
field-length word) instead of memory exhaustion per se.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-09-30 14:48:51 | Re: problems with lower() and unicode-databases |
| Previous Message | Stephan Szabo | 2004-09-30 14:34:14 | Re: string is sometimes null ? |