Re: configurability of OOM killer - Mailing list pgsql-hackers

From Tom Lane
Subject Re: configurability of OOM killer
Date
Msg-id 11881.1202054192@sss.pgh.pa.us
Whole thread Raw
In response to Re: configurability of OOM killer  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Martijn van Oosterhout <kleptog@svana.org> writes:
> Now, postgres almost certainly will never change much of it so it's not
> a big deal, but it could if it wanted to and that what overcommit was
> designed for: banking on the fact that 99% of the time, that space
> isn't written to. Overcommit is precisely what makes forking as cheap
> as threads.

Nonsense.  Copy-on-write is what makes forking as cheap as threads.

Now it's true that strict accounting requires the kernel to be prepared
to make a lot of page copies that it will never actually need in
practice.  In my mind that's what swap space is for: it's the buffer
that the kernel *would* need if there were suddenly a lot more
copies-on-write than it'd been expecting.

As already noted, code pages are generally read-only and need not factor
into the calculation at all.  I'm not sure how much potentially-writable
storage is really forked off by the postmaster, but I doubt it's in the
tens-of-MB range.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Truncate Triggers
Next
From: Peter Eisentraut
Date:
Subject: Autoconf 2.61