Re: "q" with psql display paging dumps out of psql

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> jseymour(at)linxnet(dot)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