Thread: PostGIS files for PG17-b2
I'm trying to run performance tests for the PG17-b2 release, but like b1 I don't find the PostGIS files there to complete my test suite, Normally I'd use:
sudo apt install postgresql-17-postgis-3 postgresql-17-postgis-3-scripts
But I don't see any of that available yet for 24.04 Noble Numbat. Is that normal? Should I get those from somewhere else? I know this package repo normally supplies them for the final release.
P.S.: there is a cat bump for 17b2 and you give out pg_upgrade instructions that correctly move the cluster to the new version. Works great. However, the final cleanup step recommended doesn't work:
postgres@rising:~/pgbench-tools$ rm -rf /var/tmp/postgresql-17-202405161
rm: cannot remove '/var/tmp/postgresql-17-202405161/bin/pg_resetwal': Permission denied
rm: cannot remove '/var/tmp/postgresql-17-202405161/bin/pg_walsummary': Permission denied
...
rm: cannot remove '/var/tmp/postgresql-17-202405161/lib/plpgsql.so': Permission denied
I needed an account with sudo to wipe that directory out:
sudo rm -rf /var/tmp/postgresql-17-202405161
Not sure how you want to deal with this, seems like a rough edge that should be polished before release.
sudo apt install postgresql-17-postgis-3 postgresql-17-postgis-3-scripts
But I don't see any of that available yet for 24.04 Noble Numbat. Is that normal? Should I get those from somewhere else? I know this package repo normally supplies them for the final release.
P.S.: there is a cat bump for 17b2 and you give out pg_upgrade instructions that correctly move the cluster to the new version. Works great. However, the final cleanup step recommended doesn't work:
postgres@rising:~/pgbench-tools$ rm -rf /var/tmp/postgresql-17-202405161
rm: cannot remove '/var/tmp/postgresql-17-202405161/bin/pg_resetwal': Permission denied
rm: cannot remove '/var/tmp/postgresql-17-202405161/bin/pg_walsummary': Permission denied
...
rm: cannot remove '/var/tmp/postgresql-17-202405161/lib/plpgsql.so': Permission denied
I needed an account with sudo to wipe that directory out:
sudo rm -rf /var/tmp/postgresql-17-202405161
Not sure how you want to deal with this, seems like a rough edge that should be polished before release.
--
Re: Greg Smith > But I don't see any of that available yet for 24.04 Noble Numbat. Is that > normal? Should I get those from somewhere else? I know this package repo > normally supplies them for the final release. Hi, PostGIS doesn't work with 17 yet: https://pgdgbuild.dus.dg-i.net/job/postgis-binaries-beta/93/architecture=amd64,distribution=sid/console Once that is fixed, there will be packages for PG 17. Overall status is visible there: https://pgdgbuild.dus.dg-i.net/view/Binaries-Beta/ > P.S.: there is a cat bump for 17b2 and you give out pg_upgrade > instructions that correctly move the cluster to the new version. Works > great. However, the final cleanup step recommended doesn't work: > > postgres@rising:~/pgbench-tools$ rm -rf /var/tmp/postgresql-17-202405161 > rm: cannot remove '/var/tmp/postgresql-17-202405161/bin/pg_resetwal': > Permission denied Hmm. I had thought that the other steps would already require root, but pg_upgradecluster and friends do mostly work without. I'm unsure if I want to prefix every command with "sudo" since the instructions look scary enough already. Christoph
On Mon, Jul 1, 2024 at 12:16 PM Christoph Berg <myon@debian.org> wrote:
> postgres@rising:~/pgbench-tools$ rm -rf /var/tmp/postgresql-17-202405161
> rm: cannot remove '/var/tmp/postgresql-17-202405161/bin/pg_resetwal':
> Permission denied
Hmm. I had thought that the other steps would already require root,
but pg_upgradecluster and friends do mostly work without. I'm unsure
if I want to prefix every command with "sudo" since the instructions
look scary enough already.
I was able to do all the other upgrade steps as the postgres user. If the temporary binaries were installed in the postgres user's home directory instead, the whole thing might be possible to do as postgres. Not sure what the downsides would be to relocating that block of binaries. It's really not an important problem to solve, since the catversion bump in the middle of release tweaking is a development only part of upgrading, Anyone running into this should be capable of sorting out when they need sudo. Just passing along the feedback.
Thanks for answering the PostGIS question, I will move onto other tests while waiting for that to resolve.
Re: Greg Smith > I was able to do all the other upgrade steps as the postgres user. If the > temporary binaries were installed in the postgres user's home directory > instead, the whole thing might be possible to do as postgres. The fix I applied is similar: just chown the /var/tmp/postgresql-* directory to postgres. https://salsa.debian.org/postgresql/postgresql-common/-/commit/f8061293088292fb5a08d49cd364a298bf15e1a9 Thanks, Christoph
On Wed, Jul 3, 2024 at 6:39 AM Christoph Berg <myon@debian.org> wrote:
The fix I applied is similar: just chown the /var/tmp/postgresql-*
directory to postgres.
Looks correct to me, thanks for the credit. Crunchy does a lot of RedHat oriented packaging work, I try to shore up the Ubuntu PG plumbing because I'm such a heavy user of it. I'm running PG14-17b2 right now, that server still has debris from installing with PG10, I alternate dist upgrade as practical with PGDG packaging to sample both. pg_lsclusters is the tool that keeps mel sane. Much appreciate the work you, Martin, and others have done to make all that work.
On Mon, Jul 1, 2024 at 12:16 PM Christoph Berg <myon@debian.org> wrote:
PostGIS doesn't work with 17 yet:
https://pgdgbuild.dus.dg-i.net/job/postgis-binaries-beta/93/architecture=amd64,distribution=sid/console
Since this hasn't moved yet as of beta3, I dug in. PostGIS is focused on getting PG17 well supported in their 3.5 release, currently in alpha testing, and that's probably why this rough edge has lingered around 3.4 for so long.
On the error log there's a pair of basic compiler issues and then a few regression tests are failing. Paul Ramsey dug in for me and has fixed the compiler problem:
We're not 100% sure that will fix all the regression issues, but all seems solved in his local build. He tells me it's not unusual for those particular tests to require per-version tweaks if there's still something off. I gave up on trying to build everything myself to check when I realized postgis_3.4.2+dfsg-1.pgdg+2.dsc doesn't even have PG17 listed yet.
If it takes a full release of the upstream 3.4 PostGIS branch to replace the sid 3.4.2 that's not building, we can ask Paul R to lean on speeding up the next point rel. I can't tell if that's the easiest way to navigate this through the Debian stable process, or if this is going to be a PGDG source change no matter. Baton passed to you!
--