On Wed, Dec 15, 2010 at 9:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Dec 15, 2010 at 9:47 AM, Tom Lane <tgl@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