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

On 02.09.26 20:14, Jelte Fennema-Nio wrote:
> On Tue Jul 7, 2026 at 4:52 PM CEST, Heikki Linnakangas wrote:
>> a) switch to pselect() where available, fall back to select() with
>> timeout. We don't currently use pselect() anywhere, so this needs a
>> new configure check.
>
> I've rebased again, and I realized I didn't call this out, but I went
> for the pselect approach.
>
> It would be nice to at least commit the first patch, since:
> 1. it's a nice cleanup
> 2. Michael agreed that it's fine now
> 3. it's the main thing that's requiring me to rebase this series again
>   and again.

I tested the first patch
(v12-0001-psql-Replace-cancel_pressed-with-CancelRequested.patch). It
causes a change in behavior, which might actually be good, but it should
be analyzed and called out.

Create a test table:

create table t1 (a int);

Create a test script, say test.sql:

```
\copy t1 from pstdin;
select now();
```

Then run

psql -f test.sql

When it waits for the \copy input, press Ctrl+C.

Before the patch, the \copy gets aborted and the script file continues
to run (you will see the now() output) and psql exits successfully.

After the patch, the \copy gets aborted, the rest of the script file is
not run and psql exits with code 3.

Again, this might actually be better, because non-COPY already works
this way. For example, if the script were

```
select pg_sleep(30);
select now();
```

and you pressed Ctrl+C during the sleep, the script would abort and psql
exits with code 3 as well.

If we want to make this behavior change, then this might be better done
as a separate patch before the refactoring.

The reason for this in the code is that before this patch, when psql was
waiting for the COPY input and Ctrl+C was pressed,
psql_cancel_callback() was called and then took the siglongjmp() route,
and so cancel_pressed stayed false. After the patch, handle_sigint()
sets CancelRequested = true before calling the callback. And so after
the long jump back into psql's handleCopyIn(), the flag is still true.
And then the set flag causes ExecQueryAndProcessResults() to exit.

The more I think about this, the old behavior might just be a bug. But
in any case, let's deal with it intentionally.