A bit off topic:
We implemented our own pooling mechanism which when the connection is in
the pool we set autocommit(false) thereby setting the state of the
connection to "idle" and when the pool hands out the connection we flip
it to autocommit(true). This made it much easier to find
connections/transactions orphaned by the application code.
Just food for thought.
On Thu, 2004-04-08 at 19:28, David Wall wrote:
> > Not block sorry, but the vacuum is not able to free all the row updated
> > by other connections.
>
> But each connection shouldn't have any updated rows that haven't been
> committed or rolled back. Now, if you are running some statements against a
> connection and then never calling commit/rollback, that's another thing
> since you are actually tying up resources then. But since the driver just
> does a 'begin' after any given commit/rollback, there shouldn't be anything
> locked by that connection.
>
> David
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
--
Warren Little
Senior Vice President
Secondary Marketing
Security Lending Wholesale, LC
www.securitylending.com
Tel: 866-369-7763
Fax: 866-849-8079
