On Fri, Jan 26, 2001 at 11:01:14AM +0000, Nuno Silva wrote:
[ . . . ]
> i ran across this transaction problem vs. persistent conn in pgsql some time ago.
>
> I found two workaround methods:
> - don't use persistent conn's :-) or;
> - start every conn with the usual pg_pconnect and then query a rollback to the
>server:
> $query="ROLLBACK work;"
>
> (this will kill any supposed transaction in ABORT STATE that some child had left).
>
> postgres don't support nested transactions (yet), but when it does maybe you should
>add multiple "ROLLBACK WORK;" queries :-)
Ah. Very cool. What I _still_ don't quite understand, though, is _how_
exactly this situation could come about. And what the worst case would
be. What if you don't kill the transaction in ABORT STATE?
Ta, Frank
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
