-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does not work with duckdb binary distribution #554
Comments
Rather than letting the Git repo build it from a submodule. Otherwise the pg_duckdb builder installs it into the Postgres lib directory, which isn't included in `ld`'s path, so Postgres can't find it. Update to `trunk-test-tembo:4436f19`, which includes the supported version of `libduckdb.so`. Also configure it to be added to `shared_preload_libraries` and needing to restart. Copy the same `libduckdb.so` to build `duckdb_fdw`, too, and explicitly set its version, since it may diverge from `duckdb_fdw`'s own version. The build is successful, but `duckdb_fdw` does not load with the `libduckdb.so` built by `pg_duckdb`, so skip testing it for now. Will fix once duckdb/pg_duckdb#554 or its successor resolves thing such that both extensions can use the same DSO.
Hi @theory, thanks for reporting the issue.
You can also take a look at our Dockerfile if it helps. |
Because pg_duckdb is not the only extension that needs to use
|
Hmm. Currently we compile a slightly custom build of duckdb. Due to the http request caching we support. It would definitely be nice to support running on an unmodified version, but that probably requires some changes to some changes to move the http caching to pg_duckdb (or at least detect if we run with an unmodified version so that we can disable the caching logic). It seems kinda weird that our libduckdb.so does not have that |
That's my guess as well, though I didn't see anything obvious at a glance. Equally weird that |
Rather than letting the Git repo build it from a submodule. Otherwise the pg_duckdb builder installs it into the Postgres lib directory, which isn't included in `ld`'s path, so Postgres can't find it. Update to `trunk-test-tembo:4436f19`, which includes the supported version of `libduckdb.so`. Also configure it to be added to `shared_preload_libraries` and needing to restart. Copy the same `libduckdb.so` to build `duckdb_fdw`, too, and explicitly set its version, since it may diverge from `duckdb_fdw`'s own version. The build is successful, but `duckdb_fdw` does not load with the `libduckdb.so` built by `pg_duckdb`, so skip testing it for now. Will fix once duckdb/pg_duckdb#554 or its successor resolves thing such that both extensions can use the same DSO.
What happens?
I built and installed pg_duckdb, then downloaded the latest binary release, libduckdb-linux-amd64.zip, and put
libduckdb.so
into/usr/local/lib
so that the OS would find it in theld
paths when Postgres requested it. It failed with this error:So I replaced
/usr/local/lib/libduckdb.so
with the file frompg_config --pkglibdir
(the OS cannot find it there, since it's not in theld
paths, so I don't understand whymake install
puts it there). That fixed the issue. Yay!Except that now the other DuckDB extension I'm working with, alitrack/duckdb_fdw, doesn't work with the
libduckdb.so
compiled by pg_duckdb (and I do have a symlink fromlibduckdb.1.1.3.so
so that duckdb_fdw is happy). It complains:Maddening.
Would it be possible to get pg_duckdb to work with the binary release of
libduckdb.so
? If not, is there some build configuration to get everything included? It seems like they ought to be, honestly, since ConstructMessageRecursive has been around for 2 years, and SimpleNamedParameter for four years.To Reproduce
OS:
Linux
pg_duckdb Version (if built from source use commit hash):
0.2.0
Postgres Version (if built from source use commit hash):
15.10
Hardware:
No response
Full Name:
David Wheeler
Affiliation:
Tembo
What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.
I have tested with a stable release
Did you include all relevant data sets for reproducing the issue?
Not applicable - the reproduction does not require a data set
Did you include all code required to reproduce the issue?
Did you include all relevant configuration (e.g., CPU architecture, Linux distribution) to reproduce the issue?
The text was updated successfully, but these errors were encountered: