-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160
> We're using Postgres, and we utilize a sessions table in our web app that > requires us to do a 'SELECT FOR UPDATE', which means that a second process > could block if it also calls 'SELECT FOR UPDATE'. In order to armor against > users clogging up the system, we need to be able to call $sth->cancel() if > Postgres can't respond within 30 seconds. > > However, cancel() is not implemented in DBD::Pg. I tried working around > this by using the available asynchronous query mechanism and > $sth->pg_cancel(), but it had some destabilizing effects (and I did ensure > that I called rollback() after pg_cancel())...sorry for the vagueness here). > Since we don't need asynchronous code if cancel() was implemented, then I'm > hoping to avoid it as it just creates more probability for error. I'm not sure I follow here: how would this possibly work if not through the asynchronous interface? If you are not using async, then $sth->execute() will not return control until the query is done. Being able to cancel the query is one of the two main advantages of async queries (the other being the fact that you can continue to do other things once you kick off the execute). First thing I would try is solving the problem in some other fashion: a 30 second timeout is a very rough tool. Good venues for describing the problem in more details is pgsql-gene...@postgresql.org and #postgresql on freenode. Second thing would be to figure out why pg_cancel is not working correctly for you. It should in theory have no destabilizing effects; if it does, I'd like to know about it so it can be fixed. :) - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201008041032 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkxZeiQACgkQvJuQZxSWSshakQCfRrlDPa7O3T21RTtd+RPYhjzL IpsAn3/Du9o3vh8rgMZ4ZE4q7QEZahI3 =v6q/ -----END PGP SIGNATURE-----
