On Sun, Dec 09, 2012 at 02:09:21PM -0500, Matthew Gerber wrote: > In this situation, st_transform throws an internal_error, which my > function catches and returns NULL for. The error / crash is not caused by a > NULL argument; rather, it is caused by the final value in the attached > script's INSERT statement, which contains a lat/lon pair that is beyond > PostGIS's range. I'm not questioning whether this value is actually outside > the legal range, but I do not think such an input should cause the server > to crash completely.
The server should not crash, no. However, the facts that PostGIS reported an internal error and the crash is responsive to your choice of geographic inputs increases the chance that the problem lies in PostGIS code, not PostgreSQL core code. > Here are the steps to reproduce the crash: > > 1) Create a new instance of a 9.2 server (Windows 64-bit), and a new > database (call it test) with the PostGIS extension. > > 2) Run the script: > > psql -U postgres -d test -f C:\server_crash.sql > > You should see the following: > > psql:C:/server_crash.sql:31: server closed the connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > psql:C:/server_crash.sql:31: connection to server was lost > > 3) Check your log for the error. I tried this test procedure, but I could not reproduce the crash. PostgreSQL: one click installer postgresql-9.2.2-1-windows-x64.exe; PostGIS: v2.0.1 from Stack Builder; OS: Windows Server 2008 R2 Datacenter. I needed the workaround in the last comment of this[1] bug report to get a working installation. At that point, your test procedure completes without error. What specific versions are involved in your installation? Could you try again to get a minidump and stack trace? Connect to your test database with psql; run "SELECT pg_backend_pid();"; open Visual Studio; select Debug -> Attach to process...; select the postgres.exe process with matching ID. Run your test case; when the exception window pops up, select "Break". If the stack trace does not contain full symbol information, right click on some of the incomplete lines and select Load Symbols From -> Symbol Path; navigate to the location of postgres.pdb. You can select "Save Dump As..." from the Debug menu to create the minidump. Thanks, nm [1] http://trac.osgeo.org/postgis/ticket/1824 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers