[postgis-users] Postgres Crash with st_orientation on single dataset

Tue Dec 8 19:35:49 PST 2020

Thanks, Regina - this is helpful to know.
Best,
Mike

On Tue, Dec 8, 2020 at 10:32 PM Regina Obe <lr at pcorp.us> wrote:

> Yah it is still an issue.  I’ve just reopened that ticket.  It was on me
> to provide a debug trace with SFCGAL symbols on windows so SFCGAL group
> could trace it.  Seems the issue has only happened on windows so far so
> might be windows specific.
>
>
>
> I confirmed the test Paul provided on that ticket
>
>
>
> Still crashes on windows –
>
> PostgreSQL 13.1, compiled by Visual C++ build 1914, 64-bit
>
>
>
> POSTGIS="3.1.0dev 3.1.0alpha2-157-gdfeaaac70" [EXTENSION] PGSQL="130"
> GEOS="3.9.0beta2-CAPI-0.15.1" SFCGAL="1.3.8" PROJ="6.3.2" GDAL="GDAL 3.2.0,
> released 2020/10/26" LIBXML="2.9.9" LIBJSON="0.12" LIBPROTOBUF="1.2.1"
> WAGYU="0.5.0 (Internal)" TOPOLOGY RASTER
>
>
>
> *From:* postgis-users [mailto:postgis-users-bounces at lists.osgeo.org] *On
> Behalf Of *Mike Treglia
> *Sent:* Tuesday, December 8, 2020 9:48 PM
> *To:* PostGIS Users Discussion <postgis-users at lists.osgeo.org>
> *Subject:* [postgis-users] Postgres Crash with st_orientation on single
> dataset
>
>
>
> Hi All,
>
>
>
> I was just trying to troubleshoot something with a dataset, and when
> running st_orientation on it, postgres crashes. Potentially related to this
> old bug report? https://trac.osgeo.org/postgis/ticket/3651
>
>
>
> I'm working on Windows 10, 64 bit, with Postgres 13.0, with postgres and
> postgis installed through EnterpriseDB.  PostGIS and related info is here:
>
> POSTGIS="3.0.2 3.0.2" [EXTENSION] PGSQL="130" GEOS="3.8.1-CAPI-1.13.3"
> SFCGAL="1.3.8" PROJ="6.3.2" GDAL="GDAL 3.0.4, released 2020/01/28 GDAL_DATA
> not found" LIBXML="2.9.9" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.4.3
> (Internal)" TOPOLOGY RASTER
>
>
>
> Below is the log, which includes the sql statement (I renamed the dataset
> for some data anonymity in case that matters).  I'm not sure if it's
> something about a specific feature, or the dataset itself that's causing an
> issue.
>
>
>
> Mostly just wanted to share in case it's not a known issue, and if there's
> anything else I can provide that would be useful, happy to do so (though
> the dataset is not shareable, unfortunately).
>
>
>
> Best,
>
> Mike
>
>
>
>
>
>
>
>
>
> 2020-12-08 21:32:16.998 EST [7136] LOG:  server process (PID 24536) was
> terminated by exception 0xC00000FD
> 2020-12-08 21:32:16.998 EST [7136] DETAIL:  Failed process was running:
> select st_orientation((st_dump(geom_2263)).geom) as orient, count(*) from
> nac_data.test_data
>
> group by orient
> 2020-12-08 21:32:16.998 EST [7136] HINT:  See C include file "ntstatus.h"
> for a description of the hexadecimal value.
> 2020-12-08 21:32:17.000 EST [7136] LOG:  terminating any other active
> server processes
> 2020-12-08 21:32:17.022 EST [12112] WARNING:  terminating connection
> because of crash of another server process
> 2020-12-08 21:32:17.022 EST [12112] DETAIL:  The postmaster has commanded
> this server process to roll back the current transaction and exit, because
> another server process exited abnormally and possibly corrupted shared
> memory.
> 2020-12-08 21:32:17.022 EST [12112] HINT:  In a moment you should be able
> to reconnect to the database and repeat your command.
> 2020-12-08 21:32:17.022 EST [12008] WARNING:  terminating connection
> because of crash of another server process
> 2020-12-08 21:32:17.022 EST [12008] DETAIL:  The postmaster has commanded
> this server process to roll back the current transaction and exit, because
> another server process exited abnormally and possibly corrupted shared
> memory.
> 2020-12-08 21:32:17.022 EST [12008] HINT:  In a moment you should be able
> to reconnect to the database and repeat your command.
> 2020-12-08 21:32:17.034 EST [22696] WARNING:  terminating connection
> because of crash of another server process
> 2020-12-08 21:32:17.034 EST [22696] DETAIL:  The postmaster has commanded
> this server process to roll back the current transaction and exit, because
> another server process exited abnormally and possibly corrupted shared
> memory.
> 2020-12-08 21:32:17.034 EST [22696] HINT:  In a moment you should be able
> to reconnect to the database and repeat your command.
> 2020-12-08 21:32:17.033 EST [8476] WARNING:  terminating connection
> because of crash of another server process
> 2020-12-08 21:32:17.033 EST [8476] DETAIL:  The postmaster has commanded
> this server process to roll back the current transaction and exit, because
> another server process exited abnormally and possibly corrupted shared
> memory.
> 2020-12-08 21:32:17.033 EST [8476] HINT:  In a moment you should be able
> to reconnect to the database and repeat your command.
> 2020-12-08 21:32:17.033 EST [8476] CONTEXT:  while scanning block 102119
> of relation "results_scratch.nac_ecml2"
> 2020-12-08 21:32:17.036 EST [25352] WARNING:  terminating connection
> because of crash of another server process
> 2020-12-08 21:32:17.036 EST [25352] DETAIL:  The postmaster has commanded
> this server process to roll back the current transaction and exit, because
> another server process exited abnormally and possibly corrupted shared
> memory.
> 2020-12-08 21:32:17.036 EST [25352] HINT:  In a moment you should be able
> to reconnect to the database and repeat your command.
> 2020-12-08 21:32:17.060 EST [7136] LOG:  all server processes terminated;
> reinitializing
> 2020-12-08 21:32:17.141 EST [23844] LOG:  database system was interrupted;
> last known up at 2020-12-08 21:27:47 EST
> 2020-12-08 21:32:17.195 EST [22960] FATAL:  the database system is in
> recovery mode
> 2020-12-08 21:32:17.339 EST [25660] FATAL:  the database system is in
> recovery mode
> 2020-12-08 21:32:17.406 EST [26996] FATAL:  the database system is in
> recovery mode
> 2020-12-08 21:32:17.533 EST [3096] FATAL:  the database system is in
> recovery mode
> 2020-12-08 21:32:17.621 EST [26160] FATAL:  the database system is in
> recovery mode
> 2020-12-08 21:32:17.717 EST [23828] FATAL:  the database system is in
> recovery mode
> 2020-12-08 21:32:17.747 EST [23904] FATAL:  the database system is in
> recovery mode
> 2020-12-08 21:32:17.780 EST [24808] FATAL:  the database system is in
> recovery mode
> 2020-12-08 21:32:17.846 EST [26036] FATAL:  the database system is in
> recovery mode
> 2020-12-08 21:32:17.906 EST [1116] FATAL:  the database system is in
> recovery mode
> 2020-12-08 21:32:17.976 EST [22556] FATAL:  the database system is in
> recovery mode
> 2020-12-08 21:32:18.045 EST [28448] FATAL:  the database system is in
> recovery mode
> 2020-12-08 21:32:18.107 EST [25316] FATAL:  the database system is in
> recovery mode
> 2020-12-08 21:32:18.174 EST [22180] FATAL:  the database system is in
> recovery mode
> 2020-12-08 21:32:18.238 EST [14504] FATAL:  the database system is in
> recovery mode
> 2020-12-08 21:32:18.870 EST [13132] FATAL:  the database system is in
> recovery mode
> 2020-12-08 21:32:19.802 EST [24976] FATAL:  the database system is in
> recovery mode
> 2020-12-08 21:32:20.826 EST [28144] FATAL:  the database system is in
> recovery mode
> 2020-12-08 21:32:21.857 EST [18416] FATAL:  the database system is in
> recovery mode
> 2020-12-08 21:32:21.959 EST [23844] LOG:  database system was not properly
> shut down; automatic recovery in progress
> 2020-12-08 21:32:21.971 EST [23844] LOG:  redo starts at 7/E540C568
> 2020-12-08 21:32:22.834 EST [22308] FATAL:  the database system is in
> recovery mode
> 2020-12-08 21:32:23.892 EST [22736] FATAL:  the database system is in
> recovery mode
> 2020-12-08 21:32:24.872 EST [27520] FATAL:  the database system is in
> recovery mode
> _______________________________________________
> postgis-users mailing list
> 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/20201208/52428472/attachment.html>