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

[Ivan Mincik]

I want to add to my report about a testing ms_postgis_fix_trans_state.diff 
with p.mapper that {map,layer}Obj_queryBy{Point,Rect,etc.} function is not 
working   also when  #PROCESSING "CLOSE_CONNECTION=DEFER" is disabled.
So identify object is not working at all.

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