Re: Don't use the deprecated and insecure PQcancel in our frontend tools anymore

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Subject: Re: Don't use the deprecated and insecure PQcancel in our frontend tools anymore
Date: 2026-07-06 22:12:57
Message-ID: de93d338-fc4d-4184-856a-b2c19eca0499@iki.fi
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 04/07/2026 01:28, Jelte Fennema-Nio wrote:
> On Tue, 7 Apr 2026 at 02:18, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> The cancel handling in wait_on_slots() in parallel_slot.c is surprising
>> in a different way. It already uses async libpq calls and has a select()
>> loop, but it still relies on the signal handler to do the cancellation.
>> And it arbitrarily PQcancel()s only one of the connections it waits on.
>
> Addressed this in 0002

This relies on the signal to interrupt select(), but I'm afraid that's
not guaranteed on all platforms. Also, there's a race condition if the
signal arrives *just* before you call select(). That's what the
"self-pipe hack" is for, see comments at waiteventset.c.

- Heikki

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mario González Troncoso 2026-07-06 22:26:57 Re: Possible replace of strncpy on xactdesc.c
Previous Message Zsolt Parragi 2026-07-06 22:07:35 Re: File locks for data directory lockfile in the context of Linux namespaces