On Wed, Dec 15, 2010 at 9:57 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Dec 15, 2010 at 9:47 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Yeah, and more to the point, do I want to finish whatever I was doing in >>> that window? Fast-by-default is a nice hammer to swing, but one day >>> you'll pound your finger. > >> I guess. I've pounded my finger enough time with the current default >> that I'd be willing to try a different size hammer. The scenario you >> describe has yet to occur in 10+ years of using the product, but >> obviously not everyone's experience will match on this point. > > I think the ultimate basis for the way it's set up now is the mantra of > "be safe by default"; which I believe I've heard you repeating in other > contexts. Between that principle and the backwards-compatibility > hazards, I really don't think there's adequate justification for > changing this.
Backwards compatibility is, I think, a reasonable argument for maintaining the current default. However, I don't agree that the current behavior is safe by default. What often happens is that the system gets stuck in a state where the existing connections will never terminate (or not for a long time) but new connections aren't accepted either. So you're sitting there waiting for the database to shut down - which it never does - meanwhile, half the people hitting your web site are getting DOS'd. Certainly, if you have an environment where people are mostly logging into the database directly (not through a connection pooler) and they do a few important queries and then disconnect, smart is a better default. But if you have an environment where (for whatever reason) long-lasting connections are common, smart is worse than useless. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
