Matthew Gerber <gerber.matt...@gmail.com> writes: >> Here is the command that was executing when the 0xC0000409 exception was >> raised: >> INSERT INTO places (bounding_box,country,full_name,id,name,type,url) >> VALUES >> (st_transform_null(ST_GeometryFromText('POLYGON((-97.034085 >> 32.771786,-97.034085 32.953966,-96.888789 32.953966,-96.888789 >> 32.771786,-97.034085 32.771786))',4326),26918),'United States','Irving, >> TX','dce44ec49eb788f5','Irving','city',' >> http://api.twitter.com/1/geo/id/dce44ec49eb788f5.json'),
Assuming that 0xC0000409 does actually represent a stack-overrun condition, it doesn't seem like there are very many ways that could happen on such a simple command. The best theory that is coming to mind is that you hit some corner case in the GiST code that is causing the index-entry-insertion attempt to recurse infinitely, or at least enough times to hit the stack limit. (I exclude the theory of infinite recursion in the btree indexes only on the grounds that those are so much better tested than GiST that the idea seems improbable.) It's not clear yet whether the bug is in the generic GiST code or in the PostGIS-provided index operator class. If that is the explanation, then hitting the crash would likely depend not only on the specific bounding_box value being inserted, but also on the previous state of the places_bounding_box_idx index, which could make it darn hard to reproduce. If you can't easily create a reproducer script, I think we'll have to ask you for a stack trace from the crash. See https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers