hi
i think i've encountered a bug in postgresql 8.1.
yet - i'm not reallty info submitting it to -bugs, as i have no way to
successfully redo it again.
basically
i have server, with dual opteron, 4g of memory, 2gb of swap.
everything working under centos 4.2.
what i say is that postmaster user started to "eat" memory.
it allocated *all* memory (both ram and swap), and then died.
load on the machine jumped to something around 20.
I noticed a similar occurrence. We have a high-load PostgreSQL database
-- not a ridiculous amount of inserts or updates, but a huge variety of
diverse queries on some 200 tables.
We had noticed load averages of 3-4 on our database for the past couple
days. Then, this morning, Postgres got killed twice by the Linux
out-of-memory process killer. (Also on a dual , 4GB of memory.)
We were showing 3.5 GB of memory allocated to *something*, but stopping
Postgres completely for a few seconds didn't lower the number. It wasn't
taken by any process, which leads me to believe that it's a kernel bug.
reboot later, everything is rosy -- load hovers around 1.2, there's
enough free memory to have a 2.5 GB buffer cache, and swap is untouched.
PostgreSQL 7.4 had run on this box flawlessly for six months -- bad RAM
forced us to take it down -- then again for another month until we
upgraded to 8.1 last week. Like the original poster, we're set up for
~500 MB of shared memory; certainly not enough to make the kernel kill
-9 postmaster. Kernel is 2.6.11-gentoo-r6, same as before the upgrade.
Also, this didn't happen in our test environment, which uses a similar
but x86 server. Perhaps this is AMD64 related?
Glynn
Freedom Healthcare
(end of broadcast)
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Will Glynn <wglynn (AT) freedomhealthcare (DOT) orgwrote:
Postgres completely for a few seconds didn't lower the number. It wasn't
taken by any process, which leads me to believe that it's a kernel bug.

If it was a shared memory segment allocated a particular way (I
*think* it's "shm_open", I'm not 100% sure), it's not erronious for the
kernel to leave it behind after all processes are gone see
.

If postgres needs this much shared memory and wants it to go away on
a crash, I think (again, I'm a neophyte at this still, I havent even fixed
mod_bt fo rthis yet) that an mmap()ed file is the way to go but then
don't you need enough harddrive space to support your shared memory?

I don't know, this whole things confusing
- Tyler

(end of broadcast)
TIP 3: Have you checked our extensive FAQ?