On Fri, Mar 25, 2022 at 2:47 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > I think you misunderstand where the real pain point is. The reason > that PQcancel's functionality is so limited has little to do with > blocking vs non-blocking, and everything to do with the fact that > it's designed to be safe to call from a SIGINT handler. That makes > it quite impractical to invoke OpenSSL, and probably our GSS code > as well. If we want support for all connection-time options then > we have to make a new function that does not promise signal safety.
Well, that's a fair point, but it's somewhat orthogonal to the one I'm making, which is that a non-blocking version of function X might be expected to share code or at least functionality with X itself. Having something that is named in a way that implies asynchrony without other differences but which is actually different in other important ways is no good. > I'm prepared to yield on the question of whether we should provide > a non-blocking version, though I still say that (a) an easier-to-call, > one-step blocking alternative would be good too, and (b) it should > not be designed around the assumption that there's a completely > independent state object being used to perform the cancel. Even in > the non-blocking case, callers should only deal with the original > PGconn. Well, this sounds like you're arguing for the first of the two approaches I thought would be acceptable, rather than the second. > > Leaving the question of approach aside, I think it's fairly clear that > > this patch cannot be seriously considered for v15. > > Yeah, I don't think it's anywhere near fully baked yet. On the other > hand, we do have a couple of weeks left. We do? -- Robert Haas EDB: http://www.enterprisedb.com
