On 09/29/2015 12:18 PM, Tom Lane wrote: > Andrew Dunstan <and...@dunslane.net> writes: >> On 09/29/2015 02:48 PM, Tom Lane wrote: >>> Also, perhaps we'd only enable this behavior in --enable-cassert builds, >>> to avoid any risk of a postmaster incorrectly choosing to suicide in a >>> production scenario. Or maybe that's overly conservative. > >> Not every buildfarm member uses cassert, so I'm not sure that's the best >> way to go. axolotl doesn't, and it's one of those that regularly has >> speed problems. Maybe a not-very-well-publicized GUC, or an environment >> setting? Or maybe just enable this anyway. If the data directory is gone >> what's the point in keeping the postmaster around? Shutting it down >> doesn't seem likely to cause any damage. > > The only argument I can see against just turning it on all the time is > the possibility of false positives. I mentioned ENFILE and EPERM as > foreseeable false-positive conditions, and I'm worried that there might be > others. It might be good if we have a small list of specific errnos that > cause us to conclude we should die, rather than a small list that cause us > not to. But as long as we're reasonably confident that we're seeing an > error that means somebody deleted pg_control, I think abandoning ship > is just fine.
Give me source with the change, and I'll put it on a cheap, low-bandwith AWS instance and hammer the heck out of it. That should raise any false positives we can expect. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
