PostGIS 3.6.0beta1 released

[Regina Obe]

> "Regina Obe" <lr at pcorp.us> writes:
> 
> > PostGIS 3.6.0beta1 - https://postgis.net/2025/07/PostGIS-3.6.0beta1/
> 
> NetBSD 10 amd64, geos 3.13, proj 9.6, postgresql 16.9
> built fine.
> 
> I've never been super clear on updating, but:
> 
>   gdt=> gdt=# SELECT postgis_extensions_upgrade();
>   ERROR:  syntax error at or near "gdt"
>   LINE 1: gdt=# SELECT postgis_extensions_upgrade();
>           ^
I assume this is cause you typed gdt twice?  


>   gdt=> NOTICE:  Updating extension postgis 3.4.3rc1
>   gdt-> ERROR:  extension "postgis" has no update path from version
> "3.4.3rc1" to version "ANY"

We remove alphas, betas, rcs on final release cause they take up space and
no one would be upgrading a production system from those.
Is this as a super user?  I recall we allow super users to upgrade
regardless if there is an extension path cause you can always upgrade from 
ANY and we just update the system catalogs directly to ANY if you are a
super user.

@strk is that true or did we take that logic out?


>   gdt-> CONTEXT:  SQL statement "ALTER EXTENSION postgis UPDATE TO
> "ANY";ALTER EXTENSION postgis UPDATE TO "3.6.0beta1""
>   gdt-> PL/pgSQL function postgis_extensions_upgrade(text) line 88 at
> EXECUTE
> 
> and I see it's because I must have upgraded to an rc and forgot, and
> that upgrading from that rc to (anything more than 3.4.3??) isn't
> supported.
> 
> So:
> 
>   #> l *3.4.3*
> With that, upgrade worked (with a lot of "could not check" complaints),
> and
> 
Yah I think that's expected, I think we removed that in future releases to
not tell people 
It can't upgrade extensions that don't exist.  It was a confusing notice.

>   gdt=# SELECT postgis_full_version();
> 
> postgis_full_version
>
----------------------------------------------------------------------------
----------------
>
----------------------------------------------------------------------------
------------------
>
----------------------------------------------------------------------------
------------------
>
----------------------------------------------------------------------------
------------------
> -----------------------
>    POSTGIS="3.6.0beta1 04e648e" [EXTENSION] PGSQL="160" GEOS="3.13.1-
> CAPI-1.19.2" PROJ="9.6.2 NETWORK_ENABLED=OFF
> URL_ENDPOINT=https://cdn.proj.org
> USER_WRITABLE_DIRECTORY=/tmp/proj
> DATABASE_PATH=/usr/pkg/share/proj/proj.db" (compiled against PROJ
> 9.6.2) GDAL="GDAL 3.11.3 "Eganville", released 2025/07/12"
> LIBXML="2.14.5" LIBJSON="0.18" LIBPROTOBUF="1.5.2" WAGYU="0.5.0
> (Internal)" TOPOLOGY RASTER
>   (1 row)
> 
> 
> Then tests get pretty far and error out on permissions to set
> lc_message.   Do I need to run tests as a pgsql superuser, or the owner
> of the postgis extension?
> 

> (I have recently tightened up pgsql permissions substantially:
>   - I'm no longer a superuser.
>   - pgsql listens only on unix-domain socket.
>   - pgsql has a uid map to pgsql users
>   )
> 
> 
> If the tests need privs, it would be nice to check and give a better
> message.  I realize this is likely not new in 3.6 :-)

Sounds like you are running into this issue

https://trac.osgeo.org/postgis/ticket/5212

I think the workaround is to set environment variable:
POSTGIS_REGRESS_DB_OWNER

As we do in our tests which also run sandboxed


https://git.osgeo.org/gitea/postgis/postgis/src/branch/master/.woodpecker/re
gress.yml


Yah agree we should outline this in the docs. This was a change we had to
make because of PG15 changes.

Ticketed here - https://trac.osgeo.org/postgis/ticket/5950