On Sun, May 01, 2005 at 03:09:37PM +0300, [EMAIL PROTECTED] wrote:
> Process A start to update / insert some rows in a table
> and then the connection of process A is lost to PostgreSQL
> before it sends commit or rollback. Other processes want to
> update the same rows or SELECT …..FOR UPDATE for the same
> rows.Now these processes are providing SELECT WAITING… or
> CANCEL QUERY if statement_timeout was set. Imagine these
> processes is getting grower. What will we do now ?
> Restarting backend or finding process A and kill it ?
Well, if process A loses the connection to the client, then the
transaction will be rolled back and other processes will be able to
continue.
Another thing to keep in mind is that if process A is inserting a tuple,
other processes will not see it because it isn't committed. So MVCC
rules protect them from blocking. (Unless there is a unique restriction
and some other process wants to insert the same value to it.)
Now, we do have an "availability" problem in 8.0 and earlier, which is
that you could block trying to check a foreign key that other process is
also checking. I am happy to say that it doesn't happen anymore so
that's one less barrier.
--
Alvaro Herrera (<[EMAIL PROTECTED]>)
"In fact, the basic problem with Perl 5's subroutines is that they're not
crufty enough, so the cruft leaks out into user-defined code instead, by
the Conservation of Cruft Principle." (Larry Wall, Apocalypse 6)
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
