Re: Log full with gigabyes of CurTransactionContex - Mailing list pgsql-admin

From Iñigo Martinez Lasala
Subject Re: Log full with gigabyes of CurTransactionContex
Date
Msg-id 1245078768.16064.45.camel@coyote
Whole thread Raw
In response to Re: Log full with gigabyes of CurTransactionContex  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Log full with gigabyes of CurTransactionContex  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Log full with gigabyes of CurTransactionContex  (Gurjeet Singh <singh.gurjeet@gmail.com>)
List pgsql-admin
Thank you very much, Tom.

We have increased shared buffers to 2.5GB (linux kernels allows us reach this level) and lowered work_mem to 500MB.
Let's see tonight. :-)


-----Original Message-----
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Iñigo Martinez Lasala <imartinez@vectorsf.com>
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Log full with gigabyes of CurTransactionContex
Date: Mon, 15 Jun 2009 10:02:26 -0400

Iñigo Martinez Lasala <imartinez@vectorsf.com> writes:
> We have a problem with an insert query in one of our clients. This query
> is launched in a night batch process. We have observed that if change
> set is big (more than 50.000 updates) our database log starts growing
> with thousands and thousands of lines until the server is out of space
> and database freezes.

You're running out of memory.

> work_mem = 2000MB
> maintenance_work_mem = 1024M

These two settings are probably the cause.  With shared_buffers at 2GB,
you do not have anywhere near 1GB to play around with in a 32-bit
environment.  Try something like 200M and 500M.

> Increasing temp buffers could help?

I can hardly think of anything more counterproductive.  You don't
have enough address space.
		regards, tom lane

pgsql-admin by date:

Previous
From: Gurjeet Singh
Date:
Subject: Re: Silent installation and port configuration with initdb=0
Next
From: Tom Lane
Date:
Subject: Re: Log full with gigabyes of CurTransactionContex