From: | Greg Stark <greg(dot)stark(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: problem with memory |
Date: | 2009-05-26 16:28:56 |
Message-ID: | 7D77D069-7208-4141-9C10-880F7461A60D@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
The link was to the memory context dump. The only suspicious context I
spotted was 300mb in MessageContext. What is lc_messages and lc_ctype
set to on this machine? Were the latest round of infinite recursion in
the character conversion routines in 8.3.7?
--
Greg
On 26 May 2009, at 17:00, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> one czech PostgreSQL user reports problem with memory - probable
>> memleak?
>> Is possible to diagnose some from log?
>
> If he's getting an actual "out of memory" error, let's see the memory
> context map that gets dumped to the server log (or more specifically,
> to stderr).
>
>> Server 8G RAM, 32b Debian Etch.
>> shared_buffers = 324000 # min 16 or max_connections*2, 8KB
>> each
>
> Although you may have told us enough right here. 2.5GB of shared
> buffers in a 4GB address space (with probably only 3GB available to
> the
> application) isn't a very sane choice. Back that off or run 64-bit.
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua Tolley | 2009-05-26 16:34:07 | Re: generic options for explain |
Previous Message | Tom Lane | 2009-05-26 16:18:17 | Re: PostgreSQL Developer meeting minutes up |