-
Notifications
You must be signed in to change notification settings - Fork 50
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
Upgrade to pgx 0.4.5 #408
Upgrade to pgx 0.4.5 #408
Conversation
Hmmm a failing CI / Test Updates is a little too ironic for this PR. Not sure why it didn't occur to me to check that before pushing! |
After digging around in our
and then
But we don't have a step in there for getting the right version of Will try adding a |
@rtwalker I think the issue was that the installed cargo-pgx was too old, in which case it should work with the new image... |
(we really don't want to install cargo-pgx every time we run CI, it takes much to long) |
Oh, I see, it's trying to use the compile the old version of the extension using the current pgx, which fails. ick |
Yeah...
Agree that avoiding this would be great. Is there a way to do properly do the update-tester without having the matching version of pgx? I think for now we could get away with just installing twice ( |
418: `update-tester` requires two versions of `cargo-pgx` r=rtwalker a=rtwalker Now that #417 is merged, we can change the `update-tester` crate to require two versions of `pgx` to be installed: * a 0.2-0.3 series pgx aka "old" * a 0.4 series or newer pgx (we don't actually use this one yet, but we will after #408) Rather than insisting on having the `pgx`s installed in a specific location, the update tester takes in paths to the `*/bin/cargo-pgx` subcommands as arguments and then inspects the `Cargo.toml` during the checkout of each release to determine which one to invoke. I've also updated the `tools/build` script and the `.github/workflows/ci.yml` to use the new update tester. Went ahead and bumped the `update-tester` version to `0.2.0` so I could more easily tell the difference while testing locally, though it probably makes little practical difference. Co-authored-by: Ryan Walker <rwalker@timescale.com>
418: `update-tester` requires two versions of `cargo-pgx` r=rtwalker a=rtwalker Now that #417 is merged, we can change the `update-tester` crate to require two versions of `pgx` to be installed: * a 0.2-0.3 series pgx aka "old" * a 0.4 series or newer pgx (we don't actually use this one yet, but we will after #408) Rather than insisting on having the `pgx`s installed in a specific location, the update tester takes in paths to the `*/bin/cargo-pgx` subcommands as arguments and then inspects the `Cargo.toml` during the checkout of each release to determine which one to invoke. I've also updated the `tools/build` script and the `.github/workflows/ci.yml` to use the new update tester. Went ahead and bumped the `update-tester` version to `0.2.0` so I could more easily tell the difference while testing locally, though it probably makes little practical difference. Co-authored-by: Ryan Walker <rwalker@timescale.com>
421: Don't install pgx as root or under `/` r=rtwalker a=rtwalker In #408, almost all of the CI tests are failing with permission denied errors, e.g. [here](https://github.com/timescale/timescaledb-toolkit/runs/6415824754?check_suite_focus=true#step:7:188), when trying to compile crates after running `cargo test`. This PR changes the CI Docker image to: - run all cargo commands as the "postgres" user (instead of "root") - move the pgx installations from `/pgx/0.X` to `/home/postgres/pgx/0.X` Co-authored-by: Ryan Walker <rwalker@timescale.com>
What do we have left on this? I don't understand why all the checks are failing here; I've seen all these tests (WITH 0.4!) pass on aarch64 :) Let's merge #430 first and then use 0.4.5 here though. Thanks! |
Figure out how to do the dance of getting the tests for this PR to run on the CI image that is changed in this PR.
Agreed! |
Ah. I remembered you were working on that but hadn't quite internalized. I don't think that's going to be doable. I think we'll need to change the image first. If that won't work either because the current code on main won't pass with the new image, can we change the image such that it'll support both ways? I.e.
Thanks! |
Went from 0.2.4 -> 0.3.0 -> 0.4.0 -> 0.4.3, editing the Cargo.toml, building, and testing, and the experience was largely unremarkable. Most of the changes come from followng the "Upgrading" section of the [0.4.0](https://github.com/tcdi/pgx/releases/tag/v0.4.0) release notes. Only other thing to note is that I ran into a *lot* of occurrences of the following error: ``` error[E0053]: method `input` has an incompatible type for trait --> extension/src/type_builder.rs:261:29 | 261 | fn input(input: &std::ffi::CStr) -> $name<'input> | ^^^^^^^^^^^^^^^ | | | expected struct `pgx::cstr_core::CStr`, found struct `std::ffi::CStr` | help: change the parameter type to match the trait: `&pgx::cstr_core::CStr` ``` Just blindly swapping in the `pgx::cstr_core` `CStr(ing)`s for the `std::ffi` ones made Rust much happier.
Leave TODO about making this default after merge.
was needed for #408 to pass CI
was needed for #408 to pass CI
bors r+ |
Build succeeded: |
was needed for #408 to pass CI
Now that #408 is merged, we should upgrade which pgx we use by default, i.e. which pgx is used to init the datatabases in ~/.pgx and which pgx we'll use to run our CI tests.
We added this in order for #408 to pass the CI tests. Our CI image had pgx 0.2 on its PATH, but since we were upgrading to 0.4, we wanted to use the 0.4 series pgx when running our CI tests (which use `tools/build`). This allowed us to pass our CI tests, but now that we've merged the upgrade, we don't need this, and it surely isn't useful to anyone running tests with `tools/build` locally.
Now that #408 is merged, we should upgrade which pgx we use by default, i.e. which pgx is used to init the databases in ~/.pgx and which pgx we'll use to run our CI tests.
436: change which cargo-pgx subcommand is added to PATH in CI image. r=rtwalker a=rtwalker Now that #408 is merged, we should upgrade which pgx we use by default, i.e. which pgx is used to init the databases in ~/.pgx and which pgx we'll use to run our CI tests. Co-authored-by: Ryan Walker <rwalker@timescale.com>
We added this in order for #408 to pass the CI tests. Our CI image had pgx 0.2 on its PATH, but since we were upgrading to 0.4, we wanted to use the 0.4 series pgx when running our CI tests (which use `tools/build`). This allowed us to pass our CI tests, but now that we've merged the upgrade, we don't need this, and it surely isn't useful to anyone running tests with `tools/build` locally.
We added this in order for #408 to pass the CI tests. Our CI image had pgx 0.2 on its PATH, but since we were upgrading to 0.4, we wanted to use the 0.4 series pgx when running our CI tests (which use `tools/build`). This allowed us to pass our CI tests, but now that we've merged the upgrade, we don't need this, and it surely isn't useful to anyone running tests with `tools/build` locally.
Upgrading to the latest pgx
Closes #387
Went from 0.2.4 -> 0.3.0 -> 0.4.0 -> 0.4.3, editing the Cargo.toml, building, and testing, and the experience was largely unremarkable.
Most of the changes come from followng the "Upgrading" section of the 0.4.0 release notes.
Only thing to note is that I ran into a lot of occurrences of the following error:
However, just blindly swapping in the
pgx::cstr_core
CStr(ing)
s for thestd::ffi
ones made Rust much happier.Please yell at me if that's too irresponsible.
macOS support on Apple M1 Macs
I think we should be OK to close #401 as well.
pgx
claims M1 support, and by virtue of being able to doand
where I have
I think we can claim M1 support too.