X-Original-To: pgsql-general-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id E0CD99DCAD6 for ; Wed, 22 Mar 2006 13:21:05 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 94742-06 for ; Wed, 22 Mar 2006 13:21:04 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id A89599DCA67 for ; Wed, 22 Mar 2006 13:21:03 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id k2MHL3ZH017645; Wed, 22 Mar 2006 12:21:03 -0500 (EST) To: "Rushabh Doshi" cc: "Chris" , pgsql-general@postgresql.org, pgsql-interfaces@postgresql.org Subject: Re: db sever seems to be dropping connections In-reply-to: <428B5EAB52D41B48BFE2D7D21C522D2B7C97EF@PA-EXCH01.vmware.com> References: <428B5EAB52D41B48BFE2D7D21C522D2B7C97EF@PA-EXCH01.vmware.com> Comments: In-reply-to "Rushabh Doshi" message dated "Tue, 21 Mar 2006 13:39:55 -0800" Date: Wed, 22 Mar 2006 12:21:03 -0500 Message-ID: <17644.1143048063@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.113 required=5 tests=[AWL=0.113] X-Spam-Score: 0.113 X-Spam-Level: X-Archive-Number: 200603/1005 X-Sequence-Number: 92870 "Rushabh Doshi" writes: > DBI handle: DBI::db=HASH(0x9480bdc) # this is the stale handle > DBD::Pg::db disconnect failed: rollback failed at *** line 241. > result of disconnect: > disconnect failed for DBI::db=HASH(0x9480bdc): DBD::Pg::db disconnect > failed: rollback failed at *** line 241. This seems like fairly stupid programming within DBD::Pg --- there's no reason for it to be issuing an explicit rollback command at disconnect, as the backend will certainly do that itself on seeing the connection drop. Possibly you could get the DBD::Pg developers to change that, so that a disconnect would be more robust in the face of network failure (and a tad faster too). regards, tom lane