From: | Doug McNaught <doug(at)mcnaught(dot)org> |
---|---|
To: | "Magnus Naeslund(t)" <mag(at)fbab(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PostgreSQL 7.3.4 gets killed by SIG_KILL |
Date: | 2003-12-04 13:02:10 |
Message-ID: | 8765gwzqgd.fsf@asmodeus.mcnaught.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Magnus Naeslund(t)" <mag(at)fbab(dot)net> writes:
> Doug McNaught wrote:
>> Linux is probably killing your process because it (the kernel) is low
>> on memory. Unfortunately, this happens more often with older versions
>> of the kernel. Add more RAM/swap or figure out how to make your query
>> use less memory...
>> -Doug
>
> Well this just isn't the case.
> There is no printout in kernel logs/dmesg (as it would be if the
> kernel killed it in an OOM situation).
> I have 1 GB of RAM, and 1.5 GB of swap (swap never touched).
Ahh, that's an additional piece of information hat you didn't supply
earlier. ;)
Though your system memory is ample, is it possible that you're hitting
a ulimit() on the stack size or heap size or something? I'm not sure
what signal you'd get in such a case, though.
> Is it possible to somehow find out what process sent the KILL (or if
> it's the kernel) ?
Not that I know of, unless it's in a logfile somewhere. You could try
strace(8) on the backend running the query--that might give you some
more info.
>
> I find this very weird to say the least...
Yah. You might also consider running a more recent kernel, especially
with such a big machine. 2.2.X never did play that well with large
amounts of RAM...
-Doug
From | Date | Subject | |
---|---|---|---|
Next Message | E.Rodichev | 2003-12-04 14:21:52 | Re: Encoding problem with 7.4 |
Previous Message | Jeff | 2003-12-04 13:00:14 | Re: PostgreSQL 7.3.4 gets killed by SIG_KILL |