Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 667B7475843 for ; Wed, 20 Nov 2002 19:09:42 -0500 (EST) Received: from mail1.ihs.com (mail1.ihs.com [170.207.70.222]) by postgresql.org (Postfix) with ESMTP id 269C9474E61 for ; Wed, 20 Nov 2002 19:09:40 -0500 (EST) Received: from css120.ihs.com (css120.ihs.com [170.207.105.120]) by mail1.ihs.com (8.12.6/8.12.6) with ESMTP id gAL08pGx000875; Wed, 20 Nov 2002 17:08:52 -0700 (MST) Date: Wed, 20 Nov 2002 17:09:34 -0700 (MST) From: "scott.marlowe" To: Medi Montaseri Cc: pgsql General List Subject: Re: Closing inactive connections OR user connections limits In-Reply-To: <3DDC2062.7000109@intransa.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailBodyFilter: Message body has not been filtered X-MailScanner: Found to be clean X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200211/881 X-Sequence-Number: 33302 On Wed, 20 Nov 2002, Medi Montaseri wrote: > So I think you have shown that 7.2 achieves this by skiping current > transactions.... > Thank you You're welcome. Having re-read my response, I realize now it sounded harsh, and I certainly didn't mean it that way. Usually, when a bug shows up here involving race conditions they're so rare that I've never run into them. And usually when Postgresql DOES make a mistake, it's something like permanently making a tuple undeleteable or non-vacuumable, i.e. it tends to err on the side of caution. 7.2 rocks by the way. It's rock solid for us, and we use it for dozens and dozens of projects where I work. The Postgresql hackers have what I call a "NASA space shot" mentality. Quite refreshing in a world of "weekend drag racer" developers.