Subject: PostGIS files for PG17-b2

From: Greg Smith <[email-masked]>
Date: Mon, 1 Jul 2024 12:01:19 -0400

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.

--
Greg Smith  [email-masked]
Director of Open Source Strategy

---

From: Christoph Berg <[email-masked]>
Date: Mon, 1 Jul 2024 18:16:03 +0200

Re: Greg Smith
> 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/

> rm: cannot remove '/var/tmp/postgresql-17-202405161/bin/pg_resetwal':

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

---

From: Greg Smith <[email-masked]>
Date: Mon, 1 Jul 2024 12:51:00 -0400

> 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.

---

From: Christoph Berg <[email-masked]>
Date: Wed, 3 Jul 2024 12:39:51 +0200

Re: Greg Smith
> 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

---

From: Greg Smith <[email-masked]>
Date: Wed, 3 Jul 2024 20:15:52 -0400

> The fix I applied is similar: just chown the /var/tmp/postgresql-*

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.

---

From: Greg Smith <[email-masked]>
Date: Sat, 10 Aug 2024 16:46:24 -0400

> 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:
https://github.com/postgis/postgis/commit/0a8072199200a8323b5ddcfdcb89ed01dbd5f6b1

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!