Carlos Henrique Reimer writes:
> No problem, there is no problem to use "select wm_nfsp.*" but as my concern
> is to prevent this in the future I think I should apply the fix or is there
> a config parameter to abend the backend if it reaches some kind of storage
> limit?
You could start the post
Hi Tom,
Thank you for the analyzes!
No problem, there is no problem to use "select wm_nfsp.*" but as my concern
is to prevent this in the future I think I should apply the fix or is there
a config parameter to abend the backend if it reaches some kind of storage
limit?
Thank you!
Reimer
On Tu
Carlos Henrique Reimer writes:
> That is what I got from gdb:
> ExecutorState: 11586756656 total in 1391 blocks; 4938408 free (6
> chunks); 11581818248 used
So, query-lifespan memory leak. After poking at this for a bit, I think
the problem has nothing to do with joins; more likely it's b
Hi,
That is what I got from gdb:
TopMemoryContext: 88992 total in 10 blocks; 10336 free (7 chunks); 78656
used
Type information cache: 24576 total in 2 blocks; 11888 free (5 chunks);
12688 used
Operator lookup cache: 24576 total in 2 blocks; 11888 free (5 chunks);
12688 used
Operator class
On 11/11/2012 08:54 AM, Craig Ringer wrote:
>
> Now follow Tom's advice:
>> In gdb,
>> call MemoryContextStats(TopMemoryContext)
>> should produce some useful information on the process's stderr file.
>
Oh, I forgot to explain how to actually get the output.
stderr goes to the PostgreSQL log
On 11/11/2012 12:50 AM, Carlos Henrique Reimer wrote:
> Hi,
>
> How is the best way to attach a debugger to the SELECT and identify
> why is it exhausting server storage.
This page is more focused on getting a stack trace after a crash, but
provides some information about how to identify the backe
Carlos Henrique Reimer writes:
> How is the best way to attach a debugger to the SELECT and identify why is
> it exhausting server storage.
In gdb,
call MemoryContextStats(TopMemoryContext)
should produce some useful information on the process's stderr file.
regar
Hi,
How is the best way to attach a debugger to the SELECT and identify why is
it exhausting server storage.
Thank you in advance!
On Fri, Nov 9, 2012 at 4:10 AM, Craig Ringer wrote:
> On 11/08/2012 11:35 PM, Carlos Henrique Reimer wrote:
> > Hi Craig,
> >
> > work_mem is defined with 10MB and
On 11/08/2012 11:35 PM, Carlos Henrique Reimer wrote:
> Hi Craig,
>
> work_mem is defined with 10MB and yes, there are triggers defined on
> both tables
Come to think of it, the triggers don't make any difference to memory
use for a SELECT anyway.
Your work_mem is perfectly reasonable.
The plan
Hi Craig,
work_mem is defined with 10MB and yes, there are triggers defined on both
tables:
FiscalWeb=# \d "5611_isarq".wm_nfsp
Table "5611_isarq.wm_nfsp"
Column | Type | Modifiers
---+---+---
tpdoc | smallint |
On 11/08/2012 06:20 PM, Carlos Henrique Reimer wrote:
> Is there a way to make PostgreSQL 8.3.21 server stop memory bound
> backends as PostgreSQL 9.0.0 does?
Are there any triggers on the table?
What's the setting for work_mem?
--
Craig Ringer
--
Sent via pgsql-general mailing list (pgsql-ge
11 matches
Mail list logo
