Konstantin wrote:
* Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> [Thu, 12 Feb
2009 13:54:11 +0200]:
Hmm, the first UPDATE should've blocked already. It should've fired a
RI
trigger to lock the parent tuple in shared mode, but it looks like
that's not happening for some reason.
To tell the truth I expected another behavior.
Consider example below. The difference with the first one is that there
are no attempts to modify foreign key at all, but result is the same.
...
Are you sure parent tuple should be lock in shared mode if
a) foreign key is not modified explicitly at all
b) new value of foreign key is the same as old (not changed).
Yeah, you're right, we do have that optimization. However, it doesn't
kick in when you update a tuple that you've already updated in the same
transaction. The reason is explained by this comment in trigger.c:
* There is one exception when updating FK tables: if the
* updated row was inserted by our own transaction and the
* FK is deferred, we still need to fire the trigger. This
* is because our UPDATE will invalidate the INSERT so the
* end-of-transaction INSERT RI trigger will not do
* anything, so we have to do the check for the UPDATE
* anyway.
So this is an implementation artifact, due to the way foreign keys are
implemented in PostgreSQL.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
