Attached is the latest version of this patch, which I think is now in a state in which it could be merged. The changes are:
1. Don't do host and address discovery for cancel connections. It now reuses raddr and whichhost from the original connection. This makes sure the cancel always goes to the right server, even when DNS records change or another server would be chosen now in case of connnection strings containing multiple hosts. 2. Fix the windows CI failure. This is done by both using the threadsafe code in the the dblink cancellation code, and also by not erroring a cancellation connection on windows in case of any errors. This last one is to work around the issue described in this thread: https://www.postgresql.org/message-id/flat/90b34057-4176-7bb0-0dbb-9822a5f6425b%40greiz-reinsdorf.de I also went over most of the functions that take a PGconn, to see if they needed extra checks to guard against being executed on cancel. So far all seemed fine, either they should be okay to execute against a cancellation connection, or they failed already anyway because a cancellation connection never reaches the CONNECTION_OK state. So I didn't add any checks specifically for cancel connections. I'll do this again next week with a fresh head, to see if I haven't missed any cases. I'll try to find some time early next week to implement non-blocking cancellation usage in postgres_fdw, i.e. the bonus task I mentioned in my previous email. But I don't think it's necessary to have that implemented before merging.
0002-Add-non-blocking-version-of-PQcancel.patch
Description: 0002-Add-non-blocking-version-of-PQcancel.patch