Received: from u1.abs.net (root@u1.abs.net [207.114.0.131]) by hub.org (8.8.8/8.7.5) with ESMTP id SAA25577 for ; Wed, 12 Aug 1998 18:12:36 -0400 (EDT) Received: from insightdist.com (nobody@localhost) by u1.abs.net (8.9.0/8.9.0) with UUCP id RAA18166 for pgsql-interfaces@postgreSQL.org; Wed, 12 Aug 1998 17:46:48 -0400 (EDT) X-Authentication-Warning: u1.abs.net: nobody set sender to insightdist.com!byronn using -f Received: from ceodev by insightdist.com (AIX 3.2/UCB 5.64/4.03) id AA27479; Wed, 12 Aug 1998 17:30:06 -0400 Received: from byronn by ceodev (AIX 4.1/UCB 5.64/4.03) id AA78022; Wed, 12 Aug 1998 17:30:05 -0400 Message-Id: <35D20960.B3F45788@insightdist.com> Date: Wed, 12 Aug 1998 17:30:08 -0400 From: Byron Nikolaidis X-Mailer: Mozilla 4.05 [en] (Win95; I) Mime-Version: 1.0 To: Bryan Brunton Cc: "'pgsql-interfaces@postgresql.org'" Subject: Re: [INTERFACES] Back-end problems with Delphi and ODBCExpress References: <316E0AE33DA6D1119E0D00400535C0A301EFBC@zarathustra.flesherfab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bryan Brunton wrote: > Turning off that option fixed the problem. I'm concerned that the > back-end > should be effected by this. Shouldn't it be able to recover from > confusing > statements that a ODBC driver sends it, rather than locking up like > this? > The reason it locked up with the declare/fetch option ON is because postgres cursors require a transaction to be started. The table being viewed inside the transaction is then locked from any other process even viewing it. Without the declare/fetch option, no transactions are used, so it works. The simple explanation is that the backend locking strategy needs to be improved. This is a well-known limitation of postgres that is being worked on (I believe by Vadim). He mentioned something recently on the hackers list about working on readers not locking other readers, which is exactly what is happening here. Sounded interesting. Byron