"q" with psql display paging dumps out of psql

[Jim Seymour]

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 ma*******@postgresql.org)

[Peter Eisentraut]

Jim Seymour wrote:

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

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 ma*******@postgresql.org

[Tom Lane]

js******@linxnet.com (Jim Seymour) writes:

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.
"echo $?" after it happens yields "141."
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.
I'm guessing it's some kind of race condition.

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 ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Geoffrey]

Peter Eisentraut wrote:

Jim Seymour wrote:

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

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

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

[Jim Seymour]

Tom Lane <tg*@sss.pgh.pa.us> wrote:

js******@linxnet.com (Jim Seymour) writes:

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.
"echo $?" after it happens yields "141."
141-128 = 13 = SIGPIPE. So psql is getting sigpipe'd.

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.)
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.
Dunno.

I'm guessing it's some kind of race condition.
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.

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".

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?
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.)
It seems
likely that addition or removal of --enable-thread-safety would make
a difference.

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 ma*******@postgresql.org so that your
message can get through to the mailing list cleanly