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

[Dave Fuhry]

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
>