"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Fri, 2006-11-10 at 18:55 -0500, Tom Lane wrote:
>> One thought that comes to mind is to require hash to do an smgrextend()
>> addressing the last block it intends to use whenever it allocates a new
>> batch of blocks, whereupon md.c could adopt a saner
On Nov 14, 2006, at 1:11 PM, Merlin Moncure wrote:
On 11/14/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
On Tue, Nov 14, 2006 at 09:17:08AM -0500, Merlin Moncure wrote:
> On 11/14/06, Cosimo Streppone <[EMAIL PROTECTED]> wrote:
> >I must say I lowered "shared_buffers" to 8192, as it was before.
>
OOM stands for "Out Of Memory" and it does indeed seem to be the same as
what IRIX had. I believe you can turn the feature off and also configure
its overcomitment by setting something in /proc/. and unfortunately, I
don't remember more than that.
On Thu, 16 Nov 2006, Craig A. James wrote:
Craig A. James wrote:
Russell Smith wrote:
For the third time today, our server has crashed...
I would guess it's the linux OOM if you are running linux. You need to
turn off killing of processes when you run out of memory. Are you
getting close to running out of memory?
Good suggestion,
On 11/15/06, Craig A. James <[EMAIL PROTECTED]> wrote:
Questions:
1. Any idea what happened and how I can avoid this? It's a *big* problem.
2. Why didn't the database recover? Why are there two processes
that couldn't be killed?
3. Where did the "signal 9" come from? (Nobody but me
Craig A. James wrote:
Richard Huxton wrote:
If a "kill -9" as root doesn't get rid of them, I think I'm right in
saying that it's a kernel-level problem rather than something else.
Sorry I didn't clarify that. "kill -9" did kill them. Other signals
did not. It wasn't until I manually inter
"Craig A. James" <[EMAIL PROTECTED]> writes:
> OOM? Can you give me a quick pointer to what this acronym stands for
> and how I can reconfigure it?
See "Linux Memory Overcommit" at
http://www.postgresql.org/docs/8.1/static/kernel-resources.html#AEN18128
or try googling for "OOM kill" for non-Post
Richard Huxton writes:
> Craig A. James wrote:
>> It can't be a coincidence that these were the only two processes in a
>> SELECT operation. Does the server disable signals at critical points?
> If a "kill -9" as root doesn't get rid of them, I think I'm right in
> saying that it's a kernel-le
2006/11/10, Joshua D. Drake <[EMAIL PROTECTED]>:
I would actually suggest pg_pool over pg_pconnect.
Please, can you explain advantages of pg_pool over pg_connect ?
--
Jean-Max Reymond
CKR Solutions Open Source
Nice France
http://www.ckr-solutions.com
---(end of broad
Craig A. James wrote:
By the way, in spite of my questions and concerns, I was *very*
impressed by the recovery process. I know it might seem like old hat to
you guys to watch the WAL in action, and I know on a theoretical level
it's supposed to work, but watching it recover 150 separate datab
By the way, in spite of my questions and concerns, I was *very* impressed by
the recovery process. I know it might seem like old hat to you guys to watch
the WAL in action, and I know on a theoretical level it's supposed to work, but
watching it recover 150 separate databases, and find and fix
Russell Smith wrote:
For the third time today, our server has crashed...
I would guess it's the linux OOM if you are running linux. You need to
turn off killing of processes when you run out of memory. Are you
getting close to running out of memory?
Good suggestion, it was a memory leak in
Russell Smith wrote:
Craig A. James wrote:
Questions:
1. Any idea what happened and how I can avoid this? It's a *big*
problem.
2. Why didn't the database recover? Why are there two processes
that couldn't be killed?
I'm guessing it didn't recover *because* there were two processes t
Hi Markus,
Thank you very much for the information.
I was able to make it fast by correcting indices, i created index on
frequently filtered fields.
now it runs at 0.05 seconds average, much faster than before 0.86.
I will also upgrade to 8.1.5.
Once again, thank you very much. it helped me a
14 matches
Mail list logo
