Thanks to the great suggestions I've at least gotten it to not hang... Martijn's hint about blocking led me to open up those filehandles in a non-blocking mode. It appears that write() will write, at a maximum, only 4096 bytes when it is called from within PostgreSQL. I've tried to push data into it in <=4096-byte slugs, but after 4096 bytes it just won't take anymore. Since (I think) using a non-blocking mode could cause problems with thread safety, it's probably a lost cause. I'm new to C, so this may seem extremely naive: I'm not sure how to use exec() to solve this problem. Could you give me a few pointers to get me started? --- Douglas McNaught <doug@xxxxxxxxxxxx> wrote: > Martijn van Oosterhout <kleptog@xxxxxxxxx> writes: > > > The things that have screwed me up in the past with pulling tricks like > > this are: > > > > 1. Program has registered atexit() handlers. _exit() avoids this. > > 2. Pending stdio output that gets flushed. The backend doesn't use > > stdio much so you might be fine here. > > 3. Signals. Make sure you don't get sent signals that screw state. > > Might be wise to block them all, or reset them all to default. > > > > Truly, exec() is the cleanest way to solve all this, it simply replaces > > the current process, lock, stock and barrel. > > Definitely. It would probably also be good to close all file > descriptors (except for stdin/etdout/stderr) before exec(), just in > case the other binary does something screwy with random file > descriptors (which it obviously shouldn't). > > -Doug > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster > __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
