On Mon, 23 Jun 2025 at 18:42, Jacob Champion <jacob.champ...@enterprisedb.com> wrote: > > To be clear, I'm not saying we should start throwing errors for things > > in libpq that weren't errors before. > > But that is _exactly_ what we've started doing now, in 18. We return > NULL instead of an "empty" cancellation object, and at least one > existing client fails because of it.
Ugh, I seemed to have totally misread that code when I wrote my initial note about the PG18 behaviour. Indeed PQgetCancel returning NULL obviously means that an error occurred. Also in the PQcancelCreate case, we're even setting the error message ourselves. (I did search for the error message you mentioned, but did so in psycopg (aka psycopg3), not psycopg2) > Whether that's a problem in > practice is, I guess, part of the open question of this thread. I'd love to hear what database actually has this problem. Without a specific (and non-experimental) database being impacted by this, I'm not entirely convinced that we need to do anything. If we do think it's worth it for libpq to continue to handle such systems, then I'd say we change the behaviour to only throw an error at a later point: When actually initiating the cancellation. Because it seems pretty useful to know that their attempt to cancel a query could not be serviced (just like in case of network issues). However, throwing an error in PQgetCancel or PQcancelCreate seems premature, because some clients (e.g. psycopg2) call PQgetCancel right after initializing the Postgres connection, and will thus fail the connection attempt. Effectively meaning that that client with libpq PG18 won't be able to connect to the type of server in question. > From reading this thread, I'm not convinced that's "clear". I wouldn't > have chosen the existing behavior, for sure, but any existing servers > that don't send a key must be doing _something_ with that cancel > request, right? Even if it's just ignored? I mean if the only thing a server can do is ignore it, ISTM that it's clearly useless to send it anyway. Sending nothing seems a much better choice in that case. > Do we know which implementations aren't sending keys? Nope, that's totally unclear. It would be very nice knowing which database this is, and if it's at all a production system.
