Fwd: [MAPSERVER-USERS] Fwd: CLOSE_CONNECTION=DEFER - Segmentation fault

[Ivan Mincik]

I have applied new patch ms_postgis_fix_trans_state.diff to mapserver-5.0.2 
sources from debian unstable and recompiled.

Then I have:
1. restarted apache
2. restarted postgresql-8.1
3. restarted browser (deleted cache)

And started this test with p.mapper 3.2 application:

1. Browsing the map (moving, zooming out, zooming in, adding some more layers)
2. Using identify ({map,layer}Obj_queryBy{Point,Rect,etc.}) - ERROR:  
cursor "mycursor2 immediately
3. Browsing the map (moving, zooming out, zooming in)
4. Using identify ({map,layer}Obj_queryBy{Point,Rect,etc.}) - ERROR:  
cursor "mycursor2 immediately


Result:
With this patch it is not possible to do neither a singel object query. (with 
older patch it was possible few times). 
After "ERROR:  cursor "mycursor2" does not exist" it is possible to continue 
browsing the map again and object query fill finish with same result as 
above.
   
log is here: 
http://projects.gpsmapy.sk/logs/ms_postgis_fix_trans_state_patch.log


Thanks a lot for help 
Ivan


On Wednesday 19 March 2008 23:32, you wrote:
> On Wed, Mar 19, 2008 at 3:19 PM, No Spam <nospam420 at yahoo.com> wrote:
> > --- Dave Fuhry <dfuhry at gmail.com> wrote:
> >  >    I think the correct way to solve the problem would be to first, get
> >  >  rid of the "ROLLBACK" statements in msPOSTGISLayerGetShape.  Then, in
> >  >  msPOSTGISLayerClose, call msConPoolRelease() on the connection only
> >  > if PQtransactionStatus(layerinfo->conn) == PQTRANS_INTRANS (meaning,
> >  > the connection is valid and inside a transaction block).
> >  >
> >  >    This would also solve the problem that lots of error blocks in the
> >  >  code call PQreset(layerinfo->conn).  That resets the connection but
> >  >  does not call begin a new transaction.  So when that connection was
> >  >  pulled back out of the pool, "DECLARE CURSOR ..." statements would
> >  >  fail.
> >
> >  Do you have any gut feel for the stability of the current code, and when
> > it is or is not a problem?  Does the problem only manifest itself if one
> > calls the functions: {map,layer}Obj_queryBy{Point,Rect,etc.} ?
> >
> >  I do need the patch from bug 2497 because it solves other problems that
> > I was experiencing.  And I haven't experienced any problems as a result
> > of the patch.  Nevertheless, I'm trying to decide if I've just been
> > lucky, or if I'm safe as long as I don't call those functions (I don't).
> >
> >  Thanks.
> >  - Rich
>
> Rich,
>
>    I don't have any insight into the problems you experienced with the
> mapserver process segfaulting.  I haven't seen any obvious reason why
> the older code would have caused that.
>
> Also Ivan: I've attached a patch which resolves invalid transaction
> state in a more comprehensive manner.  A new local function
> msPOSTGISInitConnection takes the reset / ROLLBACK / BEGIN steps
> necessary to fix an unusable connection.  Calls to PQreset() in the
> current code have been replaced with calls to this function, so that a
> failing query won't put a broken or non-transactional connection back
> into the connection pool.
>
>    It is only lightly tested, but if there are no bugs, it should fix
> all of the currently known problems.
>
> Thanks,
>
> Dave Fuhry