On Thu, Jun 12, 2003 at 08:08:28PM -0400, Bruce Momjian wrote: > > > > I'm unconvinced, because I've only ever heard of the problem affecting > > Postgres on Linux. > > What I don't understand is why they just don't start failing on > fork/malloc rather than killing things.
I may be way off the mark here, falling into the middle of this as I am, but it may be because the kernel overcommits the memory (which is sort of logical in a way given the way fork() works). That may mean that malloc() thinks it gets more memory and returns a pointer, but the kernel hasn't actually committed that address space yet and waits to see if it's ever going to be needed. Given the right allocation proportions, this may mean that in the end the kernel has no way to handle a shortage gracefully by causing fork() or allocations to fail. I would assume it then goes through its alternatives like scaling back its file cache--which it'd probably start to do before a lot of swapping was needed, so not much to scrape out of that barrel. After that, where do you go? Try to find a reasonable process to shoot in the head. From what I heard, although I haven't kept current, a lot of work went into selecting a "reasonable" process, so there will be some determinism. And if you have occasion to find out in the first place, "some determinism" usually means "suspiciously bad luck." Jeroen ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
