[postgis-users] "value out of range: underflow" blocking error

Thu Feb 10 12:15:44 PST 2022

Yes. That version is telling you that PostGIS was compiled with PROJ 6.3.1.

The check is done at compile time cause we have a lot of IF DEFS to handle various proj changes. 

It’s less of an issue with GEOS since with GEOS just means you will not be getting the newer features.  

For PROJ it often means misbehavior since I don’t think the major versions are completely backward compatible with older.

From: postgis-users [mailto:postgis-users-bounces at lists.osgeo.org] On Behalf Of Marco Boeringa
Sent: Thursday, February 10, 2022 2:08 AM
To: postgis-users at lists.osgeo.org
Subject: Re: [postgis-users] "value out of range: underflow" blocking error

Hi Regina,

This was over-optimistic. 

I now again see the "value out of range: underflow" error.  However, this now happened after upgrade of PROJ 6.3.1 to 8.2.0. Note that last time, I also did this upgrade, as it was a forced and automatic one suggested by the Ubuntu "Software Updater". So in both cases after restoring my VM, this update from PROJ 6.3.1 to 8.2.0 happened before the issue started appearing. So it appears the issue is related to the PROJ update, not the GEOS update as I initially suspected.

One interesting thing I noted, is that the postgis_full_version still shows 'PROJ="6.3.1"', instead of 8.2.0, despite the Synaptic Package Manager clearly showing only 8.2.0 is installed:

PostGIS version: POSTGIS="3.2.0 c3e3cc0" [EXTENSION] PGSQL="130" GEOS="3.10.1-CAPI-1.16.0" PROJ="6.3.1" LIBXML="2.9.10" LIBJSON="0.13.1" LIBPROTOBUF="1.3.3" WAGYU="0.5.0 (Internal)"

Now I remember a similar issue with outdated version number for GEOS from last year when I attempted to update GEOS from 3.6.0 to 3.8.0, where Paul remarked something like that it meant that my PostGIS "wasn't compiled with GEOS 3.8.0 support", so does this possibly also mean my current PostGIS 3.2.0 installed from the official Ubuntu repository is also not compiled with PROJ 8.2.0 support, and I should downgrade to 6.3.1?

Marco

Op 9-2-2022 om 12:57 schreef Marco Boeringa:

Hi Regina, 

After restoring my VM a second time, I dug a little deeper into the problem, and I now think I understand what went wrong: 

I had initially attempted to upgrade my GEOS 3.8.0 that comes by default in the Ubuntu 20.04 install to GEOS 3.10.1 from the 'ubuntugis-unstable' PPA. 

To do this, after adding the PPA in Ubuntu, I checked the 'libgeos3.10.1' entry in the Synaptic Package Manager, and clicked "Apply". This succeeded, but I did not uninstall 'libgeos3.8.0' in the same process, so I had two 'libgeos' versions installed. 

This seems to have caused the issue, as after I now uninstalled 'libgeos3.8.0', I noticed the Synaptic Package manager updated a couple of dependent libraries to the 3.10.1 version: 'libgeos++dev','libgeos-c1v5','libgeos-dev'. So I guess the issue with the underflow was caused by having the outdated 3.8.0 versions of these libraries still installed. 

Marco 

Op 8-2-2022 om 19:23 schreef Regina Obe: 

You have the create table statement we can test with? 

-----Original Message----- 
From: postgis-users [mailto:postgis-users-bounces at lists.osgeo.org] On 
Behalf Of Marco Boeringa 
Sent: Monday, February 7, 2022 2:34 PM 
To: postgis-users at lists.osgeo.org <mailto:postgis-users at lists.osgeo.org>  
Subject: Re: [postgis-users] "value out of range: underflow" blocking 

error 

One additional remark: in my case, there is no involvement of a GiST index 

as 

per the PostgresPro link. It fails in a "CREATE TABLE" type statement that 

also 

includes some calculations, so there isn't any indexes yet at that stage. 

Op 7-2-2022 om 08:17 schreef Marco Boeringa: 

Hi, 

Anyone else seeing this issue pop up, possibly after a recent update 
to a PostgreSQL related component, or something that PostgreSQL / 
PostGIS is dependent on? 

I am still not sure if it is caused by something in my own coding, and 
I first though this might be related to an attempt to upgrade to 
PostgreSQL 14, but after restoring my machine to PostgreSQL 13(.5), I 
still see this error blocking the successful execution of a crucial 
query in my toolchain, that used to run fine up until recently. 

I noticed there has been some very recent discussion about this same 
type of error on a PostgreSQL mailing list: 

https://postgrespro.ru/list/thread-id/2580248 

Marco 

_______________________________________________ 
postgis-users mailing list 
postgis-users at lists.osgeo.org <mailto:postgis-users at lists.osgeo.org>  
https://lists.osgeo.org/mailman/listinfo/postgis-users 

_______________________________________________ 
postgis-users mailing list 
postgis-users at lists.osgeo.org <mailto:postgis-users at lists.osgeo.org>  
https://lists.osgeo.org/mailman/listinfo/postgis-users 

_______________________________________________ 
postgis-users mailing list 
postgis-users at lists.osgeo.org <mailto:postgis-users at lists.osgeo.org>  
https://lists.osgeo.org/mailman/listinfo/postgis-users 

_______________________________________________ 
postgis-users mailing list 
postgis-users at lists.osgeo.org <mailto:postgis-users at lists.osgeo.org>  
https://lists.osgeo.org/mailman/listinfo/postgis-users 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20220210/6e028a9b/attachment.html>