PostGIS 3.6.0beta1 released

[Greg Troxel]

"Regina Obe" <lr at pcorp.us> writes:

>> "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.
>> 
>>   LINE 1: gdt=# SELECT postgis_extensions_upgrade();
>>           ^
> I assume this is cause you typed gdt twice?  

Looks liike a cut/paste error, sorry.

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

I did, but ok that's a fair point.

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

No, I decided to make myself not a super user.

I can see it needs some kind of --force, but gating on super user seems
wrong.  That's about permissions, and this is about "do you really want
to whack it, or do you want to think".   Being root shoudln't get you
out of consistency checks.

>> 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/regress.yml

My take is:

  one should be able to test without being superuser, if one can install
  postgis in a db without being superuser

  if there are extra tests one can do with superuser, then they should
  be skipped if not, reporting pass/fail/skip like most test harnesses.

  if there is a way to tell the tests to make them work, then make test
  should just do that.  putting test magic in some other place where a
  user that just runs tests per the docs is a workaround in the wrong
  place.

> 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

I don't understand why this can't just be part of "make test".

If it really can't, it should  be explained in the README where users
are told to just run tests


(Thanks for all your replies and tickets; now I get what's going on sort
of, and am confident it isn't my system being odd.)

Greg