Thread: pgbash-1.2.1 released

pgbash-1.2.1 released

From
SAKAIDA
Date:
Hi,
 I have released pgbash-1.2.1. http://www.psn.co.jp/PostgreSQL/pgbash/index-e.html
 Main updating content is next.  
1.The improvement of the interactive operational environment. 2.The addition of the original COPY (with -y option)
function.3. It is not necessary to change Makefile.  
 

# Pgbash was more excellent than psql in the  shell program,  but it was not excellent in the interactive environment.
However,in this improvement, Pgbash will be more  excellent than psql in the interactive environment too.
 

1. The improvement of the interactive operational environment.   Type 'pgbash'. pgbash> l -------------------- list
databasespgbash> sel test ------------- select * from test  pgbash> ins test col1,col2 --- copy test(col1,col2) from
stdin111    abc    efg  \.   pgbash> dt ------------------- equal to "psql \dt" pgbash> d table_name --------- equal to
"psql\d "
 

2.The addition of the original COPY (with -y option) function.
 pgbash> exec_sql -y "copy test(col1,col2) from /tmp/oo"
In COPY with -y option, it is possible to designate the column.
And, line number and error message are displayed, when the error
arises.

3. It is not necessary to change Makefile.  
Until now, changes of Makefile were necessary in order to require
the include file of bash, when the version of bash changed.  But,
in the pgbash-1.2.1, it is not necessary to change Makefile.
 
--
Regards.

SAKAIDA Masaaki  -- Osaka, Japan



Inifinite socket send from backend to java servlet

From
Rich Ryan
Date:
I'm running RH Linux 5.2, Jdk 1.1.7v3 on machine A, and RH Linux 6.1,
postgres 6.5.2 on machine B. Some queries made from A to B never return. It
looks like the java servlet on machine A skipped out on the query or the
thread died or got interrupted or something, and machine B is infinitely
waiting for it to read query results. Doing a ps -x will show several
postmaster processes doing SELECT's, but just sitting there, ( not SELECT
waiting), but not consuming any cpu time either. When I restart the web
server on machine A and then immediately look at the postgres log file on
machine B, I get a ton of these messages...

FATAL: pq_endmessage failed: errno=32
pq_flush: send() failed: Broken pipe

Within a half day or so, my database connection pool is exhausted because
there taken up by these infinite waits. Of course, I could write a db
connection timeout thread that closes these lazy connections, and I suspect
that the postmaster processes on machine B would detect the broken
connection and go away also, but still... seems like pretty icky behavior.
Any comments?
Rich




Re: [INTERFACES] Inifinite socket send from backend to java servlet

From
Tom Lane
Date:
Rich Ryan <postgres@weblynk.com> writes:
> I'm running RH Linux 5.2, Jdk 1.1.7v3 on machine A, and RH Linux 6.1,
> postgres 6.5.2 on machine B. Some queries made from A to B never return. It
> looks like the java servlet on machine A skipped out on the query or the
> thread died or got interrupted or something, and machine B is infinitely
> waiting for it to read query results.

I'm not qualified to comment on (nor interested in) the problem with the
java servlets, but I'd say they are pretty buggy if they're dying in the
middle of reading query results.

However, the backend ought to recover gracefully from client failure,
and if it's not then I'm interested in that.

> I get a ton of these messages...

> FATAL: pq_endmessage failed: errno=32
> pq_flush: send() failed: Broken pipe

> Within a half day or so, my database connection pool is exhausted because
> there taken up by these infinite waits.

What is supposed to happen is that you get a few of these messages in
the log while the backend tries to dump out the query results to the
no-longer-connected client (maybe more than a few of them, if it was a
big query :-(), and then when the backend finishes the query and tries
to read the next command from the client, it notices that the client
connection isn't there anymore, and gracefully exits.  Apparently you've
found a combination of circumstances where this doesn't happen like it's
supposed to.  I have no immediate ideas about why.  Can anyone else
reproduce this problem?
        regards, tom lane