Обсуждение: loosing connection with serial port connection

Поиск
Список
Период
Сортировка

loosing connection with serial port connection

От
"Ken J. Wright"
Дата:
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? 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'. A ps still shows the
postgres process as alive.

The postmaster startup is: /usr/bin/postmaster -i -S -D/var/lib/pgsql
The postgres process is: /usr/bin/postgres -p -Q -P5 -v 65546 databasename

Thanks,

Ken

Re: [INTERFACES] loosing connection with serial port connection

От
Tom Lane
Дата:
"Ken J. Wright" <ken@ori-ind.com> 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