Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org (8.9.1/8.9.1) with ESMTP id AAA05782 for ; Fri, 30 Oct 1998 00:00:21 -0500 (EST) (envelope-from tgl@sss.pgh.pa.us) Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id XAA17671; Thu, 29 Oct 1998 23:59:13 -0500 (EST) To: "Ken J. Wright" cc: pgsql-interfaces@postgreSQL.org Subject: Re: [INTERFACES] loosing connection with serial port connection In-reply-to: Your message of Thu, 29 Oct 1998 19:22:12 -0800 <3.0.32.19981029192210.007cf9c0@ori-ind.com> Date: Thu, 29 Oct 1998 23:59:13 -0500 Message-ID: <17669.909723553@sss.pgh.pa.us> From: Tom Lane "Ken J. Wright" writes: > RedHat Linux 5.1, PostgreSQL 6.3.2. > Are there any special considerations for running a libpq app from a > terminal hung on a serial port? In theory, no, but sometimes there's a gap between theory and practice... > This app runs fine from a local console, but dies shortly after > starting on a serial tty. What I mean by dies, is that after some > initial queries to the backend (successful) further queries will > result in an error, 'No connection to backend'. That is pretty odd, especially the part about working for a little while. > A ps still shows the postgres process as alive. And that's even odder, because the backend process would exit if it realized the connection were closed. I'll bet libpq is confused but the kernel still thinks the connection is open. Is the connection being made via Unix socket or TCP port? If you choose the other option, is the behavior any different? Is there any difference in environment (ie, environment variables --- use "env" to dump them out) between when you are logged in on the serial port and the other case? What are the last few queries you issue before the failure becomes apparent? libpq has been pretty heavily revised since 6.3.2, so it's possible that the problem would go away if you tried the current beta release (6.4-beta4) or waited till next week and tried the 6.4 official release. I'm not that interested in debugging 6.3.2 ;-), but I would be very interested in finding the cause of this behavior if it's still present in the current code. regards, tom lane