>> Here is an attempt at this. First patch contains the changes
>> second patch contains changes to psql to use this API. Docs
>> yet, pending approval of the general idea at least :)
>I think it would be better to dispense with the PQgetCancelError
>function and just make the signature of PQcancel be
> int PQcancel(PGcancel *cancel, char *errbuf, int errbuflen);
>where errbuf would normally point to a local array in the calling
>As-is, PQcancel is itself not thread safe because it is scribbling
>on the PGcancel struct. I thought the whole point of this exercise
>was to allow multiple threads to use the PGcancel struct; which seems
>to me to imply that it had better be read-only to PQcancel.
Um. Right. I somehow had it in my head that the 1 thread <-> 1 PGcancel
would always hold, in which case this would not be a problem. Now that
you put it like this, I have no idea why I made that assumption.
I'll get a new patch together using that syntax.
>We don't need the cancelConnLock if this is done properly (at least,
>assuming that storing a pointer is atomic, which seems reasonable).
Are you sure about this?
Per what docs I have, storing a pointer should always be atomic.
exchanging two pointers are not, which is why at least win32 provides a
specific function to do that (InterlockedExchangePointer).
Anyway, consider this scenario. Thread A is the mainloop thread, Thread
B is the thread that handles Ctrl-C. What if Thread B starts its run and
starts reading off the pointer. Before it's done, it's pre-empted, and
Thread A starts executing. Thread A does a free() on the memory pointed
to by the pointer. When control goes back to Thread B, it will definitly
The fact that Thread B makes kernel socket calls for possibly remote
communications only makes the probability of Thread B actually being
switched out a whole lot higher.
Or are you seeing a scenario that prevents this from happening? (I guess
we could just ignore free:ing the memory, but that seems excessibly
---------------------------(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