Re: Log full with gigabyes of CurTransactionContex
| От | Iñigo Martinez Lasala | 
|---|---|
| Тема | Re: Log full with gigabyes of CurTransactionContex | 
| Дата | |
| Msg-id | 1245081093.16064.66.camel@coyote обсуждение исходный текст | 
| Ответ на | Re: Log full with gigabyes of CurTransactionContex (Tom Lane <tgl@sss.pgh.pa.us>) | 
| Список | pgsql-admin | 
		
			 Hmmm... OK.
In parallel we have changed the procedure in order to process insert queries in smaller chunks. In our preproduction environment has solved the problem.
-----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 11:23:45 -0400
	
In parallel we have changed the procedure in order to process insert queries in smaller chunks. In our preproduction environment has solved the problem.
-----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 11:23:45 -0400
Iñigo Martinez Lasala <imartinez@vectorsf.com> writes: > We have increased shared buffers to 2.5GB (linux kernels allows us reach > this level) and lowered work_mem to 500MB. You are apparently unclear on the concept. Pushing the database to the limit of the available address space is probably going to result in failures. Redistributing a set of overoptimistic parameters into a different set of overoptimistic parameters will not fix this. regards, tom lane
В списке pgsql-admin по дате отправления: