Tom Lane conjured forth the following characters: > > > Might want to turn off dumping of core files; I believe man ulimit is > > the place to look. > > Actually, as a developer I would've first wanted to look into the core > files and try to see why they showed up in the first place. A gdb stack > trace would often tell something useful (... if not to you, then to > someone on the -hackers list ...). Cleaning up after a problem is fine, > but don't destroy the evidence until you've learned as much as you can > towards preventing the problem from happening again. We'll be a month or so to switching to 8.1, so I am sure that we'll have another core file which can kept. To the truth I haven't pursued this much because (a) it's an old revision and if time is to be spent swatting bugs it is better spent on current software, and besides it may a result of something already fixed; (b) we're almost certain that this is a result of catastrophic failures in postGIS/GEOS under load. We typically see a few connections go crazy and eat up all the RAM and CPU time; sometimes we've had to reboot to get things calm again. Our testing of 8.0 w/ postGIS 1.0 led us to conclude that we will see far less of this, in that when we replayed a day's traffic to the databases we saw no errors versus dozens from the same traffic on 7.4. When I do find another core I'll people know if you care; the chances are quite good that we find the opportunity. Alas, moving large systems in a company sometimes requires the subtle skills of a cat herder combined with the social tact of an offensive linebacker. Thanks again, G
