On Mon, 2006-03-06 at 14:33 -0500, Matthew T. O'Connor wrote: > I disagree here, a program can intelligently deal with a malloc() > failure, PostgreSQL does this very well in fact. A program can not deal > intelligently with getting killed at random moments. So I disagree that > OOM is a way of fixing the problem.
This depends on what you mean by "deal with" the problem. Queries will not be handled/answered when Pg runs out of memory, no matter HOW good it is with malloc(). Furthermore, the stack space can be exhausted. There's no way to tell for certain when this would occur - especially with recursive stack use. In _my_ opinion, it's better to simply deal with what happens when a program dies, instead of trying to prevent all the reasons that it could. It's _because_ that's my opinion that I use init. > > OOMK or not- you run out of memory, and Pg stops doing it's job. > > No, PG allocates most of what it needs on startup, a particular query > may fail due to a malloc() failure, but the postmaster will keep > running. Also, the OOM killer often does not kill the program that is > causing the OOM problem. It doesn't matter if postmaster keeps running or not. What matters is that queries will fail when the system runs out of memory. There isn't anything the daemon can do about this (short of, not using any heap or stack), and like it or not, Pg uses the heap and the stack. Also note, that if the OOMK goes off, it's because there's a problem someplace. You mention later that you're adverse to "masking" the problem- but that's exactly what turning off the OOMK does-- you have problems that need more memory than is available. > > Daemons should be resistant to accidental death. Whether it be OOMK, > > signal, or bug in the software. > > Right, and PG is, however there is a stability loss when using OOM, you > can't predict when PG will get killed, and it might not even be PG's > fault, that is, some other program might be using all the memory. That can happen anyway. See above. Note, I'm not specifically making a case for OOMK, but for init. > That's fine, but the only program I run from init are ones I don't > trust, I have never run PG from init, and I have never had a problem > with it dying. So what? > > So you say: "turn off the OOMK so Pg stays running" > > I say: "Turn off init.d so Pg stays running" > > NO PG does not stay running from init any better than from init.d, it > just gets back up faster (assuming it can be restarted). Just gets back up faster. That's the important part. If postgresql dies, nothing calls /etc/init.d/postgresql start except an ad-hoc "keepalive" script similar to the ones I mentioned earlier. I use init because it gets Pg back up faster. Now stay with me for a moment: I don't want DBMAIL to go through EXTRA CONTORTIONS that will make it difficult for me to "get it back up faster". I think that if somebody REALLY WANTS init.d to be used, their init.d script can do the daemonizing and backgrounding because the shell can already do it, and that's what they think they want. I _PERSONALLY_ don't think there's a use for init.d that involves daemons, but don't get confused by what I'm saying there: It is important to _ME_ that Pg "just gets back up faster." do realize that doesn't matter to you, all I want is for you to understand that it's important to me. If dbmail "daemonizes through weird contortions" it makes my life more difficult, and doesn't make your life any easier. If dbmail makes it easy to run from init, it makes my life easier, and doesn't make your life any more difficult. > I don't like this since it may mask a larger problem. I don't care. I want Pg to stay running. > Bottom line is PG shouldn't die very often and doesn't if it's setup properly. That's where we differ: The bottom line for me is that queries must get answered. There is no "if they don't", they simply must be answered. -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
