X-Original-To: pgsql-interfaces@postgresql.org Received: from spampd.localdomain (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 6FC49475F1C for ; Tue, 1 Apr 2003 14:45:18 -0500 (EST) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id B2A70475F26 for ; Tue, 1 Apr 2003 14:45:14 -0500 (EST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.9/8.12.9) with ESMTP id h31JjE2L002586; Tue, 1 Apr 2003 14:45:15 -0500 (EST) To: Andreas Pflug Cc: pgsql-interfaces@postgresql.org Subject: Re: nonblocking PQsendQuery will fail for querysize > 8k In-reply-to: <3E88CE22.8010503@web.de> References: <3E88CE22.8010503@web.de> Comments: In-reply-to Andreas Pflug message dated "Tue, 01 Apr 2003 01:24:18 +0200" Date: Tue, 01 Apr 2003 14:45:14 -0500 Message-ID: <2585.1049226314@sss.pgh.pa.us> From: Tom Lane X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Archive-Number: 200304/4 X-Sequence-Number: 3943 Andreas Pflug writes: > I'm having trouble with PQsendQuery if sending medium sized > queries. Everything's fine with queries up to 8190 bytes (0x1fffe), but one > byte more will not work. libpq's nonblock mode is incredibly fragile, not to say completely broken. See discussion from, eg, Jan 2000: http://archives.postgresql.org/pgsql-hackers/2000-01/msg00964.php http://archives.postgresql.org/pgsql-hackers/2000-01/msg01048.php and nearby comments. AFAIK most of those complaints never did get addressed; so the nonblock mode works under light load but falls over as soon as it's stressed at all. I'd like to see it rewritten properly, but have not had time myself. Making pqPutBytes willing to realloc the output buffer bigger would definitely help, but it's not the only thing needed to make nonblock mode robust, per comments in above messages. BTW, reallocing just big enough to handle the current input is not the way to go; that will result in lots of malloc traffic if the caller adds a few bytes at a time. I'd think about doubling the buffer size until it's big enough. Your proposed code is also nonrobust about running out of memory. regards, tom lane