Hi,

Environment:

SunOS 5.7 Generic_106541-29 sun4u sparc SUNW,UltraSPARC-IIi-Engine
Postgresql-7.4.6
Build config: --with-java --enable-thread-safety
gcc version 3.3.1
less-381
readline-4.3

$ echo $PAGER
/usr/local/bin/less
$ echo $LESS
-e

I recently upgraded from 7.4.2 to 7.4.6 and have run into a new
problem. As frequently as not, maybe even most times, when I "q" out
of paging the output of a query in psql: Instead of just quitting that
query, I get dumped straight out of psql. To add insult to injury: The
command history for the current session isn't saved. (Only what was in
the command history on entry.) It's really quite irritating :/.

It's not repeatable. If I try to trace the psql session with truss, it
doesn't do it. If I "G" to the end of the output and then "q", it
doesn't do it.

I down-graded to Postgresql-7.4.5. It happened with it. I upgraded
"less" from v332 to v381. No improvement.

"echo $?" after it happens yields "141." There is no "141" in
/usr/include/sys/errno.h.

I'm guessing it's some kind of race condition. Any suggestions where I
might start debugging this problem?

Jim

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)

Jim Seymour wrote:
Exit code 141 means signal 141 - 128 = 13 = SIGPIPE. I haven't finished
thinking what that means in this case, though ...

--
Peter Eisentraut
http://developer.postgresql.org/~petere/


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

jseymour (AT) linxnet (DOT) com (Jim Seymour) writes:
141-128 = 13 = SIGPIPE. So psql is getting sigpipe'd. The question is
why? It is set up to ignore SIGPIPE everywhere that it could reasonably
expect to get it, in particular from writing to the pager.

The timing condition involved is probably whether or not psql has
finished writing all of the query result to the pager before you
quit the pager. So if you retrieve a large query result and "q"
immediately you can probably make it more reproducible.

Also, I don't think we changed that stuff between 7.4.2 and 7.4.6
(though I haven't trawled the commit logs to make sure). Was your
7.4.2 installation also built with --enable-thread-safety? It seems
likely that addition or removal of --enable-thread-safety would make
a difference.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

Peter Eisentraut wrote:
I would expect it means the pipe between the data and pager was
inappropriately interrupted. Not that that helps a lot.

--
Until later, Geoffrey

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Tom Lane <tgl (AT) sss (DOT) pgh.pa.us> wrote:
Yeah, a couple guys on one of my IRC channels figured that out. I
subsequently smacked myself on the forehead and went "Doh!" (Been too
many years away from systems coding, I guess.)

Dunno.

I suppose anything's possible. But I usually look at the result for a
bit after querying for it , so... Anyway, I tried it on a query that
pretty reliably exhibits the problem, and no amount of waiting before
hitting "q" seems to make any difference.

By the way, I get this in the serverlog: "LOG: unexpected EOF on
client connection".

Yes, my 7.4.2 install was built with --enable-thread-safety. (In fact:
If you check the archives, you'll see it was I discovered a problem
with building with --enable-thread-safety in 7.4.2 and created a patch
to fix it.)

I was thinking of giving that a go, being as the only things I could
see in the HISTORY that looked like they might have any relationship
was "thread on Solaris" stuff. Sure enough, compiling without
--enable-thread-safety makes the problem go away.

Anything else I can try/answer for y'all?

Jim

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly