Re: [HACKERS] libpq problem

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073