Fix for "q" with psql display paging dumps out of psql

Hi,

I'm kind of wondering if anybody on the dev team noticed this and
what, if anything, they planned to do with it?

Jim

jseymour@linxnet.com (Jim Seymour) wrote:

jseymour@linxnet.com (Jim Seymour) writes:

I'm kind of wondering if anybody on the dev team noticed this and
what, if anything, they planned to do with it?

Can we make it "#ifdef SOLARIS7" somehow? I'm uneager to put a
performance penalty on every platform because of an admittedly
broken signal implementation on one.

Also, you didn't explain what changed between 7.4.2 and 7.4.6 to
make this necessary when it wasn't before.

regards, tom lane

You will be glad to know that 8.0 will use a different implementation
for thread handling of SIGPIPE, though your asynchronous handling of
SIGPIPE will still cause problems.

---------------------------------------------------------------------------

Jim Seymour wrote:

Hi,

I'm kind of wondering if anybody on the dev team noticed this and
what, if anything, they planned to do with it?

Jim

jseymour@linxnet.com (Jim Seymour) wrote:

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 ran into an annoying
problem. Thereafter, most times, "q"uitting out of paged display
output would dump me straight out of psql if the query result was
sufficiently large.

A bit of debugging revealed psql receiving a SIGPIPE to be the
problem.

Building pgsql w/o --enable-thread-safety eliminated the problem.

It looks like the culprit is asynchronous SIGPIPE signals under Solaris
7 when using thread-safe libraries. Here's a reference:
<http://www.lambdacs.com/cpt/FAQ.html#Q339&gt;.

I do not know if Solaris 8 and beyond behave this way. (Apparently
async SIGPIPE is not POSIX-compliant, so one hopes Sun has fixed this
broken behaviour.)

Here's a fix that's simple, effective and doesn't hurt anything else:

------------------------- begin included text --------------------------
*** src/bin/psql/print.c-orig   Wed Nov 17 08:04:47 2004
--- src/bin/psql/print.c        Sat Nov 20 10:43:22 2004
***************
*** 1119,1124 ****
--- 1119,1128 ----
{
pclose(output);
#ifndef WIN32
+               /* The SIG_IGN is to compensate for broken Solaris 7
+                * (async) SIGPIPE handling with --enable-thread-safety
+                */
+               pqsignal(SIGPIPE, SIG_IGN);
pqsignal(SIGPIPE, SIG_DFL);
#endif
}
-------------------------- end included text ---------------------------

Thanks to Andrew, over at SuperNews, for the idea.

Regards,
Jim

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

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

jseymour@linxnet.com (Jim Seymour) writes:

I'm kind of wondering if anybody on the dev team noticed this and
what, if anything, they planned to do with it?

Can we make it "#ifdef SOLARIS7" somehow? I'm uneager to put a
performance penalty on every platform because of an admittedly
broken signal implementation on one.

I don't have a problem with #ifdef'ing it in/out. But will an extra
pqsignal() call at that point would incur an appreciable performance
penalty?

Also, you didn't explain what changed between 7.4.2 and 7.4.6 to
make this necessary when it wasn't before.

That would involve extensive slogging though the code, identifying all
the changes made between 7.4.2 and who-knows-what-version (the problem
exists with 7.4.5, as well) and working-out their impact.

Yeah, it's a kludgy fix. I certainly won't be offended if you don't
care to address this problem--particularly if you don't care to use
that fix.

Jim

Bruce Momjian <pgman@candle.pha.pa.us> wrote:

You will be glad to know that 8.0 will use a different implementation
for thread handling of SIGPIPE, though your asynchronous handling of
SIGPIPE will still cause problems.

So-noted.

Jim