libpq problem

Andreas Pflug wrote:

Some recent change in libpq seems to interfere with gtk.

After I tested a new pgadmin3 version on linuy yesterday, I found that
the GUI is hanging after PQconnectdb was called. After the call, the db
connection is fully functional, but the GUI mouse will show "waiting"
and the program doesn't react to mouse clicks any more; screen updates
are not performed either.

When I replace the 8.0 libpq.so* version with an older saved version
(7.4.3 from debian installation) it works ok.

OK, I found out. Seems I didn't run make distclean for a longer time, so
I didn't realize earlier.

The reason is the sigpipe handling code. If the app (in this case: some
gtk internals) already installed a SIGPIPE handler, the thread_in_send
key is not created. pthread_setspecific calls will thus use an invalid
key, which screws up gtk.

The attached patch will implement two features:
1) unconditionally create thread_in_send
2) Always register our own SIGPIPE handler, chain to a previously
registered handler when the signal is thrown while not sending.

Regards,
Andreas

Am Mittwoch, 11. August 2004 15:07 schrieb Andreas Pflug:

Some recent change in libpq seems to interfere with gtk.

You could use "nm" to find common symbols that might be clashing. Besides
that, it's hard to tell more. Alternatively, compile with versioned symbols
and see whether the problem goes away.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

OK, I like your idea of chaining on to any existing SIGPIPE handler
rather than just do it if none is installed. I also see your fix for
the uninitialized thread-specific variable.

I added some comments to the patch, renamed the pipeheader variable so
it was pg_* to avoid namespace conflicts, and updated the documentation.

Patch attached and applied.

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

Andreas Pflug wrote:

Andreas Pflug wrote:

Some recent change in libpq seems to interfere with gtk.

After I tested a new pgadmin3 version on linuy yesterday, I found that
the GUI is hanging after PQconnectdb was called. After the call, the db
connection is fully functional, but the GUI mouse will show "waiting"
and the program doesn't react to mouse clicks any more; screen updates
are not performed either.

When I replace the 8.0 libpq.so* version with an older saved version
(7.4.3 from debian installation) it works ok.

OK, I found out. Seems I didn't run make distclean for a longer time, so
I didn't realize earlier.

The reason is the sigpipe handling code. If the app (in this case: some
gtk internals) already installed a SIGPIPE handler, the thread_in_send
key is not created. pthread_setspecific calls will thus use an invalid
key, which screws up gtk.

The attached patch will implement two features:
1) unconditionally create thread_in_send
2) Always register our own SIGPIPE handler, chain to a previously
registered handler when the signal is thrown while not sending.

Regards,
Andreas

---------------------------(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

Bruce Momjian wrote:

OK, I like your idea of chaining on to any existing SIGPIPE handler
rather than just do it if none is installed. I also see your fix for
the uninitialized thread-specific variable.

I added some comments to the patch, renamed the pipeheader variable so
it was pg_* to avoid namespace conflicts, and updated the documentation.

Patch attached and applied.

At a glance, this looks like it will break applications that pass
SA_SIGINFO in sa_flags for their SIGPIPE handlers. This changes the
expected signal handler signature to a three-arg form; the extra two
args provide context about where the signal occurred. The libpq handler,
however, doesn't pass those args when chaining to the next handler.

The Sun JVM under linux is one example of an app that does1 this. I've
seen a similar problem to this before with a version of libnss_ldap that
did not correctly restore the entire sigaction state when restoring the
SIGPIPE handler before returning from libnss_ldap .. the next SIGPIPE
that arrives would crash the JVM. See
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4630104 for more
details (requires registration)

-O