Manfred Spraul wrote: > >This seems workable as long as we document the possible gotchas. > > > > > > > Is that really worthwhile? There are half a dozend assumption about the > C library and kernel internal efficiency of the signal handling > functions in the proposal. Adding a PQinitLib function is obviously a
The main path uses pthread_sigmask() and sigpending(). Are those possible performance problems? I see how signal() would be a thread problem, but not those. > larger change, but it solves the problem. > I'm aware of one minor gotcha: PQinSend() is not usable right now: it > relies on the initialization of pq_thread_in_send, which is only created > in the middle of the first connectDB(). That makes proper signal > handling for the first connection impossible. I think that whole PQinSend thing is pretty ugly, even if I did write it. My current patch seems like a great improvement. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(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
