Re: Add non-blocking version of PQcancel - Mailing list pgsql-hackers

From Jelte Fennema
Subject Re: Add non-blocking version of PQcancel
Date
Msg-id HE1PR8303MB00732A831BE871DF360A293CF7E09@HE1PR8303MB0073.EURPRD83.prod.outlook.com
Whole thread Raw
In response to Re: Add non-blocking version of PQcancel  (Jelte Fennema <Jelte.Fennema@microsoft.com>)
Responses Re: Add non-blocking version of PQcancel  (Jelte Fennema <Jelte.Fennema@microsoft.com>)
List pgsql-hackers
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.
Attachment

pgsql-hackers by date:

Previous
From: Matthias van de Meent
Date:
Subject: Re: Restructure ALTER TABLE notes to clarify table rewrites and verification scans
Next
From: Julien Rouhaud
Date:
Subject: Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements