Received: from emu.prod.itd.earthlink.net (emu.prod.itd.earthlink.net [207.217.121.31]) by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f0HNVt075867 for ; Wed, 17 Jan 2001 18:31:55 -0500 (EST) (envelope-from craig@red-bean.com) Received: from krazykat (dialup-63.214.200.19.Philadelphia1.Level3.net [63.214.200.19]) by emu.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id PAA11262 for ; Wed, 17 Jan 2001 15:31:51 -0800 (PST) Received: by krazykat (Postfix, from userid 1000) id CE03523823; Wed, 17 Jan 2001 18:32:56 -0500 (EST) To: pgsql-interfaces@postgresql.org Subject: issues with libpg interface From: Craig Brozefsky Date: 17 Jan 2001 18:32:56 -0500 Message-ID: <87itndwy8n.fsf@piracy.red-bean.com> Lines: 43 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Archive-Number: 200101/181 X-Sequence-Number: 799 We have two situations that have arisen while using libpq thru CMUCL bindings in our UncommonSQL package. We have a multi-processing application which uses a pool of database connections to perform DB queries. The first one is that we are getting unexpected retun values from pgresultstatus after calling pgexec, a value of PGRES_TUPLES_OK. The thing is that we're not sending a SELECT, just UPDATES, INSERTS and DELETES. My understanding is that none of those return tuples. Here is the message our interface spits out. ;; Warning, database-execute-command: Recieved tuples ok in response to UPDATE WCO_ALLOCATION SET CANCELLED_TIME = '2001-01-12 16:50:10+00',DELETED_AGENT_ID = 0,PICKUP = 'f',RETURN_AGENT_ID = 7104,NON_EXPIRING = 'f',INSTRUCTIONS = '',BUILDING_PASSES = 'NIL',ACCOMPANYING_PEOPLE = 'NIL',PICKUP_PEOPLE = 'NIL',COMMENTS = '',CREATED_TIME = '2001-01-12 16:50:50+00',REPEAT_RULE = 'NIL',END_TIME = '2001-01-16 17:48:00+00',START_TIME = '2001-01-12 16:50:50+00',AGENT_ID = 6761,CUSTOMER_ID = 3970,LOCATION_ID = 4,ALLOCATION_TYPE = 'COMPLETED-CHECKOUT',ALLOCATION_ID = 34166 WHERE WCO_ALLOCATION.ALLOCATION_ID = 34166 So, is it possible for an UPDATE to correctly return PGRES_TUPLES_OK, or are we seeing some confusion in the backend or libpq due to load and multi-processing? Also, unrelated, I think, to the above issue, we are getting the following message intermittently: Backend message type 0x50 arrived while idle I cannot find any more information about this message in the documentation, so I don't know what type of message that is. -- Craig Brozefsky In the rich man's house there is nowhere to spit but in his face -- Diogenes