We don’t distribute postgis binaries for Debian/ubuntu systems. That is done
by apt.postgresql.org. So they would need to make the change if any change
needs made.
I think PostGIS works fine with any LLVM but it sounds like maybe PostGIS was
compiled with LLVM 14 and you have 15 installed
I know we’ve had issues with jit in the past slowing things down or other
issues and somewhere along the line they defaulted jit to be on. Before it
used to be by default off.
Can you try disabling JIT and then run the query again.
SET jit = off;
Rerun your query:
Also did you on
> Since the upgrade to Debian trixie with PostgreSQL 17.6 and PostGIS 3.5.2 the
> queries to fetch all ways connected to a boundary with nodes within a
> bounding box are terribly slow.
>
>
> osm-nl=# SELECT postgis_full_version();
>
> postgis_full_version
> -
> On 9/9/25 8:32 PM, Paul Ramsey wrote:
> > It’s a shame you cannot provide the selectivity on the other machine,
> because this way we are just guessing. The fact that selectivity is coming
> back
> at zero does maybe indicate a change in selectivity calculations, and zero is
> smaller than a lot
> As noted by Paul our selectivity is just screwed up and probably has been
> since 3.4.
> I'm still surprised though that it chose to use a GIST over an exact btree
> where
> your node.id is the primary key.
>
> I sadly stupidly dropped the gist index on mine to prove the point to myself
> that
Минин
Sent: Tuesday, September 16, 2025 1:41 PM
To: Regina Obe
Cc: postgis-users
Subject: Re: RE: backend error after upgrading to 3.6.0
I've already tried and with JIT off it works.
"Also did you only upgrade PostGIS or did you upgrade PostgreSQL as well."
PostGIS only. Postgr
> On 2025-09-15 19:16 +0200, Ярослав Минин via postgis-users wrote:
> >
> > Hello! We have stumbled upon a strange issue after upgrading from
> > PostGIS 3.3.0 to 3.6.0.
> > A simple query like select * from foo.bar where ST_IsValid(geometry)
> > executed in DBeaver returns the following error:
>
since you are more likely to run into fat geographies than you are fat
geometries.
> -Original Message-
> From: nikolai.berkoff
> Sent: Tuesday, September 9, 2025 3:01 PM
> To: Regina Obe
> Cc: postgis-users@lists.osgeo.org
> Subject: RE: Geometry / geography w
> Dropping the index is not what you want, because you still want it for other
> queries. You do want a way to not use the index for this query where it's
> detrimental.
>
> Isn't the OFFSET 0 trick a way to manipulate the query planner to avoid using
> the detrimental index on its first try?
>
>
> There is only a single version of postgresql & postgis in the Debian stable
> repos, pgdg packages are not used.
>
> > - Can you check the PostGIS selectivity estimate on the old and the
> > new installations, using
> >
> > SELECT _postgis_selectivity ('nodes', 'geom',
> > ST_GeomFromEWKT('SRID
> On 9/9/25 6:27 AM, Sebastiaan Couwenberg via postgis-users wrote:
> > On 9/9/25 6:04 AM, Regina Obe wrote:
> >> To take GEOS out of the equation, what is performance if you just do below
> compared to your old performance
> >
> > That is significantly faster:
> Hi,
>
> I noticed 3.6.0 became available on Ubuntu 24.04 where I am currently
> running my PostgreSQL / PostGIS install.
>
> However, after adding the 'postgis_sfcgal' extension and the PostGIS
> extension upgrades using "SELECT postgis_extensions_upgrade();", attempting
> to use the new 'CG_Si
> On debian 12, PG 15, gdal 3.6.2 is the latest system pkg.
>
> However, I've built PostGIS 3.5.3 with non-system pkg GDAL 3.11.3. That
> GDAL version is built with the latest non-system pkg geos 3.14 and sfcgal
> 2.3.0.
>
> I can build PostGIS with the latest non-system pkg GDAL, but not the lat
PostGIS 3.6.0 is released. You should be seeing it appear in package repos
soon.
Details here - https://postgis.net/2025/09/PostGIS-3.6.0/
Supported versions of PostgreSQL are 12-18beta3
Please report issues by replying to this email or reporting on our ticket
tracker -
https://trac.osgeo.org
Roland,
Just a clarification here. ST_3DIntersection, just got a renaming to
CG_3DIntersection to make it clear it's an SFCGAL function as discussed
here - https://trac.osgeo.org/postgis/ticket/5405 so it will still be
available in 3.5 and beyond.
This is to prevent confusion of what is SFCGAL
keted here:
https://trac.osgeo.org/postgis/ticket/5978
From: Regina Obe
Sent: Monday, August 25, 2025 3:15 PM
To: 'Michael Downey' ; 'postgis-users@lists.osgeo.org'
Cc: 'Jonathan Shim' ; 'Ale Raza' ;
'Yung-Ting Chen' ; &#x
We did remove constraint support in geometry_columns where and since you are
using constraints that would do it.
Though I thought we did that in upcoming PostGIS 3.6.0 not PostGIS 3.5.3,
but I guess I was mistaken. It was done in 3.5.3.
https://trac.osgeo.org/postgis/ticket/5829
Any re
> Can you suggest me a way?
>
> > For a nice overview of all this see e.g.
> > https://kartoweb.itc.nl/geometrics
>
> I think, I don't have the needed mathematical knowledge to understand that...
> :(
>
> I try to explain again what I need...
> I created an image, putting more tiles together. Th
> Am 19.08.2025 12:25, schrieb Greg Troxel:
>
> Hi Greg,
>
> > If you aren't using postgis, then your question is really off topic!
>
> I know it and I already said it at the beginning...
>
> > In that case, you should use gdal, which also uses proj. And, it can
> > read/write postgis.
> >
> >
We've extended the Call for Proposals. Submissions at this point will be
accepted on a rolling basis.
https://talks.osgeo.org/foss4g-na-2025/
Conference will be Nov 3rd-5th in Reston, VA, USA
Details here - https://www.foss4gna.org/
Thanks,
Regina
> > But if you added it to proj.db too with just the new srid you added in
> spatial_ref_sys wouldn't it read from proj.db?
>
> Yeah, but, why? I don’t tend to think of proj.db as something normal humans
> mess with, and definitely since it’s bundled with the proj software packages
> there’s a lik
>
> > On May 21, 2025, at 7:43 AM, Regina Obe wrote:
> >
> > The general advice is if you want to make changes, you should make it in
> your proj.db database since that is the first source of truth for PostGIS
> these
> days.
> >
>
> Er, not really. If
I’m guessing that limit might have come from our source early on. In the early
years we only used proj4text field.
The general advice is if you want to make changes, you should make it in your
proj.db database since that is the first source of truth for PostGIS these days.
The spatial_ref_s
PostGIS team is pleased to release PostGIS 3.5.3 and PostGIS 3.6.0alpha1.
These are the first releases to support PostgreSQL 18 and should work fine
with recently released PostgreSQL 18beta1.
Details here:
PostGIS 3.6.0alpha1 - https://postgis.net/2025/05/PostGIS-3.6.0alpha1/
PostGIS 3.5.3 - htt
> Hello,
>
> Bellow my case and the steps to reproduce :
>
> /* About my database */
> SELECT VERSION();
> -- PostgreSQL 16.4, compiled by Visual C++ build 1941, 64-bit SELECT
> POSTGIS_VERSION();
> -- 3.4 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
>
> /* Create a table with a generic geometry column wit
I don’t think OpenStreetMap data is going to help you with constructing flight
corridors. As I recall these are 3 dimensional areal paths.
You ultimately need 3 dimensional data – data that has altitude restrictions,
and the city point in openstreetmap is pretty useless as I think that might
j
James,
I don’t think that section checks against spatial_ref_sys at all.
The issue we ran into before when spatial_ref_sys was checked was when there is
say an index that uses a ST_Transform or a function used in a table constraint
that relies on spatial_ref_sys.
In those cases though
Hmm I would have expected that to work. To be honest, I've never tried
building postgis from source on Centos. I just always use the packages from
yum.postgresql.org
I suppose it could be for whatever reason the paths aren't set and pointing at
pg_config is not sufficent. When I build under
The PostGIS 3.5.2 has been released.
Details here: https://postgis.net/2025/01/PostGIS-3.5.2/
I personally want to release within the next 1-2 weeks cause we found some
other issues we’d like to address as well.
But we have to discuss first.
Thanks,
Regina
From: Łukasz Szałek via postgis-users
Sent: Tuesday, January 7, 2025 12:53 PM
To: Paul Ramsey
Cc: PostGIS Users D
Why isn’t ST_DWithin being used here?
I thought we had native curve distance checking with ST_DWithin as well.
From: Paul Ramsey
Sent: Tuesday, January 7, 2025 1:37 PM
To: Andrea Aime
Cc: PostGIS Users Discussion
Subject: Re: Intersection tests with curved polygons
I’m not 100% sure
Thanks for the input Arthur.
Much appreciated,
Regina
From: Arthur Bazin
Sent: Monday, January 6, 2025 3:16 PM
To: Regina Obe
Subject: Re: Do you use PostGIS BRIN?
Hi,
Always have used GiST index, never BRIN.
I do a lots of DB audit for many clients and I have never seen any
We are thinking of removing BRIN support in PostGIS because it has a serious
bug as discussed here.
https://lists.osgeo.org/pipermail/postgis-devel/2025-January/030457.html
and here - https://trac.osgeo.org/postgis/ticket/5564
that currently causes crashes during Index building.
The two options
ALTER EXTENSION runs.
So that is why I was asking you to reset it for the session.
That said I forget if the search_path is also reset during ALTER EXTENSION so
that may not work anyway.
From: kaido vaikla
Sent: Tuesday, December 24, 2024 5:51 AM
To: Regina Obe
Cc: postgis-users
tonio
Il Lun 23 Dic 2024, 23:52 Regina Obe mailto:l...@pcorp.us> > ha
scritto:
Best to keep conversation on the list. Added back postgis-users.
I think what might do what you want here is combination of ST_Boundary,
ST_Union, and ST_Polygonize
1. Get the linework of t
I vaguely recall running into this issue when doing CREATE EXTENSION
postgis_topology; But haven’t seen the issue in recent versions of postgis
(e.g. 3.4 and above) and can’t remember how I worked around it.
Is your search_path set just for your user setting or for the database?
Have
om
FROM b;
From: Antonio Valanzano
Sent: Monday, December 23, 2024 6:37 AM
To: Regina Obe
Subject: Re: ST_Union behaviour
Regina, thanks for the fast reply.
I am unioning 4 distinct polygons(see attached polygon_overlapping.jpeg) which
present some overlapping (some areas with
Are you unioning one geometry or many?
The only reason I can think of why ST_Union would return unchanged overlapping
polygons is if you fed it a geometry collection or invalid multipolygon with
overlapping polygons.
In these cases you should be using ST_UnaryUnion
https://postgis.net/d
The following patch releases are available now.
Details at
https://postgis.net/2024/12/PostGIS-Patch-Releases/
If you run into any issues report on https://trac.osgeo.org/postgis
Thank you and Happy Holidays,
PostGIS Development Team
By example of query, I meant a simple self-standing query that has the geometry
in question that is being converted to a geometry collection.
> > > I suppose, in the last versions of PostGIS the Function ST_Makevalid
> > > will return something other than in the previous one.
> >
> > Some informa
> Hi again
>
> > I suppose, in the last versions of PostGIS the Function ST_Makevalid
> > will return something other than in the previous one.
>
> Some information more...
>
> It seems, in some cases, the function ST_Makevalid returns
> ST_GeometryCollection instead of ST_MultiPolygon...
> Why?
sing computed tile size: 215x274
or
INFO: Using computed tile size: 97x46
or
INFO: Using computed tile size: 18x10
Just testing and thinking out loud!
Best,
Andreas
On Sun, Dec 15, 2024 at 12:35 AM Regina Obe mailto:l...@pcorp.us> > wrote:
Sorry haven’t had a
/www.dropbox.com/scl/fo/bk8cwktahry0oj0ab2rsz/AHdTD73unb4Efxtgf7exfm0?rlkey=esjtw2iyzysan2hdqklwmj5e3&st=hupv5tsr&dl=0>
&st=hupv5tsr&dl=0
Best,
Andreas
On Thu, Dec 12, 2024 at 3:26 PM Regina Obe mailto:l...@pcorp.us> > wrote:
Andreas,
Yes I would expect them to give the s
Andreas,
Yes I would expect them to give the same result.
What version of raster2pgsql are you running? It should tell you if you run
raster2pgsql without any args.
Also what platform are you on? Any chance you have some of those tiles
available so we can check it out?
From: And
> Łukasz Szałek via postgis-users writes:
>
> > I am waiting over two months for a POSTGIS with fix related to ST_UNION and
> lost SRID. Does anyone know when a fix will be released in new POSTGIS
> package?
>
> If it is fixed but not in a release, you could look in the sources and find
> the f
Paolo,
I think a long time ago I used to have the commandline tools also available as
a separate download. I guess I can start that again if enough people find that
valuable.
From: Gandalf the Gray
Sent: Monday, November 18, 2024 8:46 AM
To: Paolo Cavallini ; PostGIS Users Discussio
Not sure how you ended up with an alpha2, I had removed that in the final
release thinking no one would be running with that that wasn’t building there
own.
To fix:
UPDATE pg_extension SET extversion = 'ANY' where extname LIKE 'postgis%';
And then run the process again.
From: Ant
Are you building your own postgis and this is during regression testing?
Did you build your own PostgreSQL?
I think I’ve run into that issue before when I was testing against my meson
built PostgreSQL. I think it might be those additional // causing the issue.
e.g. has /tmp/pgis_reg/pgis
The main overhead I see with postgis raster are the following
1. Limitation of raster sizes of about 1GB as I recall
2. Detoasting of data which is almost always needed
https://www.postgresql.org/docs/current/storage-toast.html
3. Mem copying of data, probably more so than usin
Is there a reason you don't want to set it at the database or system level.
ALTER DATABASE treintaytres SET postgis.gdal_enabled_drivers = 'ENABLE_ALL';
Then I think the setting would apply to any user.
> -Original Message-
> From: thi...@gelassene-pferde.biz
> Sent: Saturday, November
You confirmed that your source table has no NULL geometries?
From: Robert Hewlett
Sent: Wednesday, October 23, 2024 9:17 AM
To: postgis-users@lists.osgeo.org
Subject: Null geometries for CREATE TABLE AS ... SELECT *
Hi,
Any reason or thoughts on why CREATE TABLE AS ... SELECT * would
> Greetings,
>
> What is the highest version of PostGIS that can be used with PostgreSQL
v10?
> (The matrix only goes back to PostgreSQL v11.) We're doing an upgrade
from
> v10 to v17, and we want to minimize the number of "hops" of
> PostGIS/PostgreSQL upgrading. Thanks!=
PostGIS 3.2 as noted
,
Regina
From: Kered
Sent: Tuesday, October 8, 2024 3:46 PM
To: Regina Obe
Subject: Re: Failure during Postgres major version upgrade due to deprecated
long_xact funcs
Hi Regina,
After adding those two to postgis_legacy.c and rebuilding it, now upgrade can
complete. Thanks for the
Thanks for the alert. I suspect we forgot to add that function to
postgis_legacy, so that needs to be done. We’ll do that in next 3.4. patch
update.
For now I recommend before upgrading (especially with pg_upgrade) dropping it
in the extension.
So
ALTER EXTENSION "postgis" DROP FU
This does not surprise me. I think Paul wrote that note 15 years ago and even
then I don't recall it making a significant difference and back then we weren't
even using geographylib and think we are now even for sphere.
We should probably take that not out of the docs.
Paul you have anything to
PostGIS development team is pleased to release PostGIS 3.5.0.
This release works with PostgreSQL 12-17 and GEOS 3.8_ and PROJ 6.1+
Details of release at:
https://postgis.net/2024/09/PostGIS-3.5.0/
Please report on our ticket tracker if you run into issues
https://trac.osgeo.org/postgis
Thanks
Details of release here: https://postgis.net/2024/09/PostGIS-3.5.0rc1/
Changes since:
#5779 Failures building in parallel mode (Sandro Santilli)
#5778, Sections missing in What's new (Regina Obe)
Source: https://download.osgeo.org/postgis/source/postgis-3.5.0rc1.tar.gz
NEWS:
Details at: https://postgis.net/2024/09/PostGIS-3.5.0beta1/
This version requires PostgreSQL 12 - 17, GEOS 3.8 or higher, and Proj 6.1+.
To take advantage of all features, GEOS 3.12+ is needed.
If you are running with GEOS 3.13.0 you should experience improved
performance with many relation
Yes. Running twice second run is supposed to repackage postgis_raster.
If the repackaging works, then to drop raster just do:
DROP EXTENSION postgis_raster;
If drop extension works, no need to run that uninstall_rtpostgis.sql script.
If it doesn’t work then you need to run uninstal
Reminder Early Bird registration for FOSS4G NA is ending today August 8th.
https://www.foss4gna.org/
Happening - SEPT 9-11 | ST LOUIS, MO
Also workshop slots are filling up, register for a workshop before it's too
late.
We've got workshops for
pgRouting
PostGIS
pg_vector (Vector DBS)
Apac
Sorry about that. I guess the services didn’t come back after my patch updates.
Should be all set now.
From: Gandalf the Gray
Sent: Thursday, August 8, 2024 1:25 AM
To: PostGIS Users Discussion
Subject: PostGIS Winnie
Hi guys.
I have reported this a while back to the dev ML, but
For basic boolean logic, I would highly suggest just using Reclass, as it’s
much faster
https://postgis.net/docs/RT_ST_Reclass.html
Generally speaking I think any algebraic operations and I recall even CASE
statements allowed in SQL are allowed though I haven’t fully tested that.
If you ar
PostGIS 3.5.0alpha2 is released. This version fixes an issue with the tar
ball that made it fail because of test failures
discovered by Bas Couwenberg
https://trac.osgeo.org/postgis/ticket/5759
This version requires PostgreSQL 12 - 17, GEOS 3.8 or higher, and Proj 6.1+.
To take advantage of all
I've pushed out PostGIS 3.5.0alpha1 release. This is the first release to
work with PostgreSQL 17.
This version requires PostgreSQL 12 - 17, GEOS 3.8 or higher, and Proj 6.1+.
To take advantage of all features, GEOS 3.12+ is needed. To take advantage
of all SFCGAL features, SFCGAL 1.5.0+ is neede
Usually the reasons I get that error are
1. You did not reconnect after setting search_path of the database. The
search path if set at the db level, does not take effect until after
reconnection.
2. You did not give permissions to those functions or usage to the schema.
From: B
If you haven't submitted a talk for FOSS4GNA 2024 https://www.foss4gna.org/,
there is still sometime.
The hard close for talks is June 30th, but don't wait till the last minute
since we may close before then.
Get your talk in before it's too late.
https://talks.osgeo.org/foss4g-na-2024/
It is al
Which system are you on? A apt or Yum based?
It sounds like maybe you are picking up LLVM from your OS repo, and bits from
the PGDG repo.
You should probably disable your OS repo LLVM
Or report issue to
https://www.postgresql.org/list/pgsql-pkg-yum/ (CentOS / Redhat / Rocky)
The FOSS4GNA 2024 Conference will be happening September 9th-11th in Saint
Louis, MO, USA
https://foss4gna.org/
We are accepting call for presentations thru June 2nd, at
https://talks.osgeo.org/foss4g-na-2024/cfp
So just 1 week left.
Presentations can be
20-30 minute Talks
3-hr Workshops
Post
> "Regina Obe" writes:
>
> > Paul and Sandro,
> >
> > Any thoughts on this. I know we went back and forth with "Why don't
> > we just populate spatial_ref_sys using postgis_srs_all or some other
> > such thing or why don't we just c
> > Which I can't find in our spatial_ref_sys table (guess our table needs
> > an update), but you can add with the below as long as you are using
> > PostGIS 2.5 or higher and PROJ 7 or higher, it's going to relegate all the
> details to PROJ anyway So the other columns will not be needed except t
Not sure what you mean by dynamic attributes.
If you need something to position points along a line, so that you can put
an info tip on each point, they youll want to use
https://postgis.net/docs/en/ST_LineInterpolatePoints.html
Something like below will give you a point every 20 perce
Gandalf,
Just a followup to this discussion we had in November -
https://lists.osgeo.org/pipermail/postgis-users/2023-November/046247.html
Wasn't sure if you had any luck compiling pgSphere. I looked at it again
and was able to.
I reported the issue I had, and they are planning to make some re
2, but you are
running with 3.11.1. In theory that shouldn't be an issue since 3.10.2 is
upward compatible with 3.11.
Everything else at a glance looks to be in shape.
Hope that helps,
Regina
From: Jeffrey Durrence
Sent: Tuesday, April 23, 2024 1:21 PM
To: Regina Obe
What does
SELECT postgis_full_version();
Run on your current setup vs. your Azure VM setup.
Might thinking is it might be a dependent library crashing.
Usually the issues are with postgis_raster extension since that drags in
GDAL which drags in several more libraries.
Could a
I'd check to make sure hibernate has usage rights and execute for all
functions.
I recall they changed that in PG 15 I think it was.
From: Bekir Niyaz
Sent: Wednesday, April 3, 2024 4:52 AM
To: postgis-users@lists.osgeo.org
Subject: need help
Hello again I updated postgis from 3.0 to
Should be back up now.
From: Gandalf the Gray
Sent: Thursday, April 4, 2024 4:32 AM
To: PostGIS Users Discussion
Subject: Buildbot
Hi guys.
It seems Winnie is down again.
Pieter
> [... deleting for the sake of brevity ...]
>
> >> This SQL variant does not return errors, but it isn't visible in my
> >> QGIS
> > project
> >> (it's an ongoing project with about twenty layers built with PostGIS).
> >>
> >> Any advice?
> >>
> >> Should I direct this inquiry to the QGIS list?
>
> The reason is that it doesn't seem that QGIS can work w TEMP tables.
>
TEMP tables are only visible to the session that created them, so not a huge
surprise QGIS can't work with them.
I use them mostly to store intermediary results before dumping to another
table.
> From this, I want to create
> Thank you again; results are starting to come in.
>
> Apologies for starting a new thread; but the other one was getting messy.
>
> Here are the queries that I am testing:
> SELECT city, state, ST_ClusterDBScan( ST_Transform(geom,2163), eps :=
> 0.3048*5000, minpoints :=1) OVER () AS cluster_id
> Depends where you got the data, but generally if they give you longitude
> latitude Columns, then 4326 is a safe assumption and looks like you created
> the geometry right too.
>
> To Gary's point, 4326 is degree based, so no wonder you aren't getting any
> meaningful answers since 1000 would co
> On Thu, 28 Mar 2024, Gary Turner wrote:
>
> >
> > On 28/03/2024 12:32 pm, Max Pyziur wrote:
> >> On Wed, 27 Mar 2024, Regina Obe wrote:
> >>
> >>> That's the function I would have suggested.
> >>>
> >>> What query are
That's the function I would have suggested.
What query are you trying to run and what is the spatial reference system id
for your data.
I'm guessing the issue might be your units of measure. If you want to do
500 ft you'd be best using a meter or mile based spatial reference system.
> -Orig
On DBeaver this is how it shows the rotated raster.
On DBeaver this is how it shows the rotated polygon and then converted to
raster.
On Tuesday, March 19th, 2024 at 14:58, Regina Obe mailto:l...@pcorp.us> > wrote:
An easier way to compare what is happening is to
I don’t think so. As I recall when you do a pg_dump, it just stores the
CREATE EXTENSION … line without a VERSION so you can’t tell.
I could be mistaken though.
From: B H
Sent: Friday, March 22, 2024 2:50 PM
To: PostGIS Users Discussion
Subject: Determining postgis version from pg_
_rotated_from_raster_05;
-- st_width | st_height | st_skewx
-- --+---+---------
-- 1000 | 1000 | 0.09481479675190897
Cheers,
Eloi
On Monday, March 18th, 2024 at 14:01, Regina Obe mailto:l...@pcorp.us> > wrote:
By size, what do you
By size, what do you mean exactly? It would change the width and height.
What are you expecting rotation to do. Perhaps you can give example out of the
below and some sample
ST_Width, ST_Height, ST_SkewX before and after and what you were expecting.
https://postgis.net/docs/en/RT_ST
There isn’t a single guide I can think of.
Generally the key factors I can think of for speeding intersects, are make sure
you have spatial indexes in place, parallelization, and memory.
Here is one that details how to config params for parallelization
http://blog.cleverelephant.ca/20
And the query?
From: Shaozhong SHI
Sent: Monday, March 18, 2024 7:57 AM
To: Regina Obe
Cc: PostGIS Users Discussion
Subject: Re: PostGIS performance issue
product_assurance=# SELECT version(), postgis_full_version();
version
Sent: Sunday, March 17, 2024 9:49 AM
To: Regina Obe
Cc: PostGIS Users Discussion
Subject: Re: Database crash when creating raster_in function
I am are using raster extension
The creation of raster_in function breaks on PG15 as well, JFYI, I have created
package for 3.3.5 on rhel7(this is
Yap that was fixed in PostGIS 3.3.3.
The change there was to support a change in PG16, so you shouldn’t need it for
upgrading from PG13 to PG15.
Are you using postgis_raster or you just have it installed?
If you don’t need postgis_raster, I would suggest uninstalling it before
upgrading.
> Hi,
>
> On Tue, 2024-03-12 at 15:12 +0530, Nikhil Shetty wrote:
> > I have a requirement to go with v3.3.3 for RHEL8 as of now.
>
> What forces you to install and old and buggy version?
>
Yah PostGIS 3.3.6 is latest for 3.3 minor and 3.3 is not the latest stable
minor.
I would push back on t
You are missing double-quotes, on the xmlns schemes, but even putting those
in, I still get an ERROR: invalid GML representation
I haven't tried ST_GeomFromGML with curved geometries before or added
namespaces, so it's possible curves are not supported since there is no
mention on the page
1:05 AM
To: Regina Obe
Cc: PostGIS Users Discussion
Subject: Re: The intersect function does not utilize indexes
I am very happy to have found the reason.
The client's development database is based on pg12. They modified the nodes.h
file and added two enumerations
hack the
version checks in postgis_extensions_upgrade().
From: Nikhil Shetty
Sent: Monday, February 26, 2024 11:20 AM
To: Regina Obe
Cc: PostGIS Users Discussion
Subject: Re: Options to rollback PostGIS upgrade
Hi Regina,
We are upgrading from 3.1.2 to 3.3.3.
So, after we run
Which version of PostGIS are you coming from again?
In theory, as long as your old is running a newish PostGIS 3+, it should be
safe enough to just NOT run
SELECT postgis_extensions_upgrade();
If you don’t run that, then your database is just running with a newer lib
file, but old scr
yum.postgresql.org has already discontinued support for rhel-7 so I would
presume so.
From: Nikhil Shetty
Sent: Monday, February 26, 2024 6:27 AM
To: PostGIS Users Discussion
Subject: PostGIS 3.3 latest releases unavailable for rhel7
Hi Team,
I was not able to find the rpm packages
: Dapeng Wang
Sent: Sunday, February 25, 2024 9:09 AM
To: Regina Obe
Cc: PostGIS Users Discussion
Subject: Re: The intersect function does not utilize indexes
The version installed is 3.4.1, which is already the latest version. I'll
navigate upwards from the "Cache Lookup Error&qu
postgis_full_version();
Doesn’t say you need updates. If it does make sure to run
SELECT postgis_extensions_upgrade();
From: Dapeng Wang
Sent: Friday, February 23, 2024 8:25 PM
To: Regina Obe
Cc: PostGIS Users Discussion
Subject: Re: The intersect function does not utilize indexes
The
You have an example query where you are seeing this behavior?
From: Dapeng Wang
Sent: Thursday, February 22, 2024 8:57 PM
To: PostGIS Users Discussion
Subject: The intersect function does not utilize indexes
Hello everyone,
I have a client with a database developed on PostgreSQL 12,
Possible or one of the dependencies is different, or planner differences such
as the CTE changes that came in PostgreSQL 12, but hard to tell given the
information you have provided
Or you didn’t reindex your data after the upgrade to a newer version of
PostgreSQL and such a reindex was require
1 - 100 of 782 matches
Mail list logo
