Re: "q" with psql display paging dumps out of psql - Mailing list pgsql-general

From jseymour@linxnet.com (Jim Seymour)
Subject Re: "q" with psql display paging dumps out of psql
Date
Msg-id 20041115220748.7D33D430E@jimsun.linxnet.com
Whole thread Raw
In response to Re: "q" with psql display paging dumps out of psql  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
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

pgsql-general by date:

Previous
From: Nadeem Bitar
Date:
Subject: Oracle versus PostgreSQL
Next
From: Chris Browne
Date:
Subject: Re: 24x7x365 high-volume ops ideas