Обсуждение: "q" with psql display paging dumps out of psql

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

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/

jseymour@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

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

Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> jseymour@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