DuckDBQueryOrThrow does not respond to cancel requests

[cobolbaby]

What happens?

When I install the extension in the private network, it hangs for a long time. If I try to use pg_terminate_backend to terminate the execution, It still fails to be canceled.

To Reproduce

OS:

Linux

pg_duckdb Version (if built from source use commit hash):

66cb6e64feb40bc1b0a7511485703442e39e60ad

Postgres Version (if built from source use commit hash):

16.8

Hardware:

No response

Full Name:

Cobolbaby

Affiliation:

Inventec

What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.

I have not tested with any build

Did you include all relevant data sets for reproducing the issue?

No - Other reason (please specify in the issue body)

Did you include all code required to reproduce the issue?

• [ ] Yes, I have

Did you include all relevant configuration (e.g., CPU architecture, Linux distribution) to reproduce the issue?

• [ ] Yes, I have

[JelteF]

Okay, so looking at the report, I think the main issue here is that our internal DuckDBQueryOrThrow function does not handle cancel requests (at all). That's indeed something we should fix. I don't consider this super urgent, since we normally don't use DuckDBQueryOrThrow for queries that we expect to take a long time.

An easy way to reproduce this is by using duckdb.raw_query() with some long running query and seeing that pressing Ctrl+C has no effect. For example the following query takes ~18 seconds on my machine to complete and I have no way of canceling it in the middle:

select duckdb.raw_query($$ select count(*) from generate_series(100000000000) $$);

[cobolbaby]

Issue +1, unable to cancel the request:

SELECT * FROM read_parquet('s3://table-data/smt-componentTrace/OF4CPT0152/ComponentTrace.*.parquet')

[JelteF]

Hmm, that's a different problem then. That query is not using DuckDBQueryOrThrow internally. Do you what it's doing while it's stuck? e.g. is CPU high or can you get a backtrace from the process during this time.

Are the files you're trying to access actually reachable, or is it again because you cannot make outgoing requests due to your network?

[cobolbaby]

Are the files you're trying to access actually reachable, or is it again because you cannot make outgoing requests due to your network?

You’re absolutely right—the file being accessed does not exist, but the S3 service is accessible.