Search Postgresql Archives

Re: Win32 Backend Cash - pre-existing shared memory block is still in use

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks. So can you explain why 512mb is bad decision here given that I only have 3.7GB of RAM? 

The reason why I want the temp_buffers set so high is because this server is used for large data warehousing type queries. The server has very few sessions simultaneously running on it, but each session can create large temp tables.

Thanks
Jeremy

-----Original Message-----
From: Scott Marlowe [mailto:scott.marlowe@xxxxxxxxx] 
Sent: Wednesday, August 25, 2010 5:11 PM
To: Jeremy Palmer
Cc: Magnus Hagander; Tom Lane; pgsql-general@xxxxxxxxxxxxxx; Alvaro Herrera
Subject: Re:  Win32 Backend Cash - pre-existing shared memory block is still in use

512M is still REALLY high for a 32 bit postgresql.  Have you tried
something in the 16Meg range?

On Tue, Aug 24, 2010 at 10:31 PM, Jeremy Palmer <JPalmer@xxxxxxxxxxxx> wrote:
> Bugger I got another crash on the server today even after setting the temp_buffers to 512MB. Has anyone got any suggestions to fix this issue?
>
> Should I just compile the source using MS visual studio, then debug and get a stack trace for someone to diagnose on this list?
>
> Thanks
> Jeremy
>
> -----Original Message-----
> From: Jeremy Palmer
> Sent: Friday, August 20, 2010 1:52 PM
> To: 'Magnus Hagander'; Tom Lane
> Cc: pgsql-general@xxxxxxxxxxxxxx; Alvaro Herrera; Chris Crook
> Subject: RE:  Win32 Backend Cash - pre-existing shared memory block is still in use
>
> Yes I do realise that temp_buffers is per backend. I set it like this because we only have a few simultaneous clients connecting, and these clients generally run large analysis queries that usually create big temp tables.
>
> I turned on extra logging and I have tracked down the query that is crashing the backend. The query was making a really big temp table. By setting the temp_buffers to 512MB the queries no longer crashes the backend.
>
> My question is what is a safe value for the temp_buffers parameter on a win32 system? Also how can we stop PostgreSQL crashing because of this issue? I'm willing provide more information to help diagnose this.
>
> Regards,
> Jeremy
>
> -----Original Message-----
> From: Magnus Hagander [mailto:magnus@xxxxxxxxxxxx]
> Sent: Friday, August 20, 2010 1:46 AM
> To: Tom Lane
> Cc: Jeremy Palmer; pgsql-general@xxxxxxxxxxxxxx; Alvaro Herrera
> Subject: Re:  Win32 Backend Cash - pre-existing shared memory block is still in use
>
> On Thu, Aug 19, 2010 at 15:42, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
>> Jeremy Palmer <JPalmer@xxxxxxxxxxxx> writes:
>>> Could it be that I have too much memory allocated for postgresql? My resource settings are:
>>> shared_buffers = 94952
>>> temp_buffers = 1GB
>>> work_mem = 19339
>>> maintenance_work_mem = 191845
>>> max_stack_depth = 2MB
>>
>> 1GB for temp_buffers is a *LOT*.  You do realize that's per backend?
>> Those other settings don't look too unreasonable.
>
> Definitely - particularly since this is a 32-bit version, that's
> getting very close to the address space limits...
>
> --
>  Magnus Hagander
>  Me: http://www.hagander.net/
>  Work: http://www.redpill-linpro.com/
> ______________________________________________________________________________________________________
>
> This message contains information, which is confidential and may be subject to legal privilege.
> If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message.
> If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info@xxxxxxxxxxxx) and destroy the original message.
> LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ.
>
> Thank you.
> ______________________________________________________________________________________________________
>
> --
> Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>



-- 
To understand recursion, one must first understand recursion.
______________________________________________________________________________________________________

This message contains information, which is confidential and may be subject to legal privilege. 
If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message.
If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info@xxxxxxxxxxxx) and destroy the original message.
LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ.

Thank you.
______________________________________________________________________________________________________

-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux