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

[Dave Fuhry]

Ivan,

   Try the new version of the patch, just posted.  I had accidentally
removed a necessary query in msPOSTGISLayerGetShape.  My tests which
now include getShape() are working (with or without PROCESSING
"CLOSE_CONNECTION=DEFER").

   Don't forget to copy the new php_mapscript.so into your apache
modules directory after rebuilding, too.  Best to delete it before
building, so you're sure it regenerated.

   By the way, your earlier log showed that the new
msPOSTGISInitConnection function seems to be working correctly.  New
connections are initialized with just one  BEGIN, and ROLLBACKs are
followed by BEGINs.  Good to see that; the "transaction already in
progress" warnings should be gone for good.

Thanks,

Dave


On Thu, Mar 20, 2008 at 6:06 PM, Dave Fuhry <dfuhry at gmail.com> wrote:
> Ivan,
>
>    I figured out why my examples were not triggering your problem: I
>  was calling $layer->getResult() but not $layer->getShape().
>  getShape() calls  msPOSTGISLayerWhichShapes which contains the
>  "mycursor2" code.  I'm looking at it.
>
>    In the meantime, your log appears confusing, because it doesn't
>  show the failing SQL statement which caused the mycursor2 error.  I
>  think my suggestion to use the "log_min_duration_statement = 0" in
>  postgresql.conf was a bad one.  Instead, comment that back out and try
>  the log_statement parameter.  Set it to "log_statement = 'all'".  That
>  should cause the log to show failed statements, too.  So your "ERROR:
>  cursor "mycursor2" does not exist" lines will be preceded by the SQL
>  which caused them (obviously helpful).
>
>    I'll see if I can send an updated patch pretty soon.
>
>  Thanks,
>
>  Dave
>
>
>
>  On Thu, Mar 20, 2008 at 2:14 PM, Ivan Mincik <ivan.mincik at gmail.com> wrote:
>  > 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
>  >
>