crasher with 2 geography columns in view used in query

[robe]

I'm having a crasher using a view that has two geography columns. Running the view works fine but when incorporated into thiss particular query

Gives this message in the logs before the process kills the service

 server process (PID 5448) exited with exit code 128

I'm going to try to reduce it down to the elements, but writing this here to remind myself.

It's a funny thing because the query we have doesn't even use geography - no output of it and even if I stuff a spatial distance output in the view it doesn't crash when used by this query.

I had put in the geography columns for a different use but when we have it in the view that this query uses, it consistently crashes. When we take geography columns out of the view it works fine.

This is with PostGIS 2.0.1. and I had revised the view recently to include more columns (including 2 geogs) and to my shock our app kept crashing the PostgreSQL service when this key search query was run.

It's a query involving time ranges and other sub selects, but no spatial part. My first guess is it has something to do with the self-join and many geogs.

So the view itself — runs fine — it joins twice with an airports table that has geog (one for each side of a trip).

Then the query it self that is crashing joins twice with the view, but never selects the geog columns or even uses them.

Platform:

Windows 2008 64-bit running: PostgreSQL 9.1.4, compiled by Visual C++ build 1500, 32-bit POSTGIS="2.0.1 r9979" GEOS="3.3.5-CAPI-1.7.5" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.9.1, released 2012/05/15" LIBXML="2.7.8" LIBJSON="UNKNOWN" RASTER

[pramsey]

Regina you haven't included anything I could use to replicate this issue.

[robe]

I know. That's cause I'm still working on a small test to replicate the issue. I'm avoiding the issue in our code at the moment by removing the geography columns from the view. None of the sub queries run separately triggers the bug. It's only in unison that it crashes.

I suppose I could try removing the index from the airports table to see if its an issue with the index. Though the query in question I don't think ever uses the spatial index.

[robe]

Nevermind. I must be losing my mind. I put the geography columns back in and it works fine. Though before I could have sworn restarting the service did no good.