> It does a SELECT ... FOR UPDATE because we don't have a
> SELECT ... AND PLEASE DO NOT REMOVE.
>
> If we would only check if the PK is there now, another
> concurrent transaction could delete the PK, it's own check
> cannot see our uncommitted row yet and we end up with a
> violation. And if you look at the comment a few lines up, it
> explains why we cannot skip the check even if the key value
> doesn't change.
But it does not apply here since there are no "on update set default" here. So IMO this case should not apply if there
arenot "on update set default"? Or are other cases where the same restriction applies?
The problem is this, at the moment there is no such thing as "row level locking" in postgres when you use foreign key
constraints.This really hits concurrency.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com