Fwd: [MAPSERVER-USERS] Fwd: CLOSE_CONNECTION=DEFER - Segmentation fault
Ivan Mincik
ivan.mincik at gmail.com
Thu Mar 20 11:14:40 PDT 2008
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
More information about the MapServer-users
mailing list