pg_duckdb / Tableau

[jdu]

We're having a fairly odd issues with pg_duckdb on pg16.

We've got a table in our data lake (S3) which we expose via a view in our pg16 warehouse as a view (duckdb query) over the parquet file.

For a given user, with a USER MAPPING with key/secret, we can query that view as the user perfectly fine from tools like DataGrip, or psycopg in python, or PGAdmin. As well, we can query the table from Tableau Desktop perfectly fine using the normal Tableau postgres connector, or the postgres JDBC connector.

When we move that workbook to our tableau server though, everything seems to change. Same user, Same warehouse behind the scenes, with the same USER MAPPING and keys. But when the extract tries to run the query to pull the views data, we get a 403 forbidden HTTP GET error with what appears to be an incorrect endpoint structure for the S3 bucket:

https://our-bucket-name.s3.amazonaws.com/path/file.parquet is the path the extract process complains about, but pretty sure that it should be https://our-bucket-name.s3.region.amazonaws.com/path/file.parquet. We've tried setting the endpoint on the USER MAPPING and we already set the region on it. The tableau server is in the same VPC and subnet as the postgres warehouse so I don't think it's down to network path at all.

Any ideas how Tableau might be interacting with it's postgres connection in a way that alters how the duckdb query under the hood would operate? Some sort of changes to the session that could cause something like this?

[YuweiXiao]

Hi, can you check if the secret is injected into the duckdb session by select * from duckdb.raw_query($$from duckdb_secrets();$$)

BTW, if you have access to server log, maybe enable log_statement='all' and collect the behaviour difference.

[jdu]

I've been crawling through the pg logs this morning, and there doesn't seem to be anything particularly weird about the way tableau is querying:

2026-02-10 09:26:00.264 UTC,"<USERNAME>","warehouse",869771,"10.60.66.154:34232",698af9a4.d458b,68,"BIND",2026-02-10 09:25:56 UTC,11/119930,0,ERROR,XX000,"(PGDuckDB/Duckdb_BeginCustomScan_Cpp) Executor Err
or: DuckDB re-planning failed: HTTP Error: HTTP GET error on 'https://<BUCKET_NAME>.s3.amazonaws.com/WAREHOUSE/theme_grants/grant_outputs/grant_outputs.parquet' (HTTP 403)",,,,,,"SELECT ""applications_and_grants""
.""application_form_url"" AS ""application_form_url"", 

(clipped the rest of the query which is just a FROM to the view backed by pg_duckdb)

If I pull this query and run it with the same user from DataGrip it runs perfectly fine.

Before it runs that query, the only things I can see it running is a BEGIN before that, I think I already have log_statement='all' on already, but will double-check that momentarily.

[jdu]

So the query above is a join between a normal PG table and a duckdb-backed view over a read_parquet. I can set up an extract that queries the duckdb-backed view fine, and the extract runs. But when that table is joined to a standard Postgres table, tableau throws the error about the HTTP GET

[jdu]

I suspect it's something to do with the join between a PG table and a duckdb-backed view. We have 4 other extracts which extract duckdb-backed views only and they are working fine, the only difference between those and this one is that this one joins to a PG table...

[jdu]

Have upgraded the version of pg_duckdb to v1.1.1 that we're running (still on pg16), and get a little bit more detail from the error. It's saying no credentials provided in the error message in Tableaus jobs UI along with the standard HTTP GET info.

So the user has credentials through USER MAPPING, we have a view which is a SELECT ... FROM read_parquet('s3://blah/foobar.parquet')

Tableau is trying to query a PG table, joining the duckdb-backed view to the PG table, and somewhere, the USER MAPPING credentials aren't propagating to allow duckdb to query the parquet.

[jdu]

This is very much a tableau thing. We've swapped to using an embedded JDBC postgres connection and the join works and executes fine. So there's something that tableau does with the native connector it ships with that fudges up duckdb.

[YuweiXiao]

I had a case where the duckdb session was reset and the secrets were not reloaded to the new session (It is bug actually). But it only happens if the duckdb txn aborts or is manually reset (e.g., through recycle_ddb()). Not sure if it applies in your cases.

I fixed my case by adding a InvalidateDuckDBSecrets() in DuckDBManager::Reset().