Re: BUG #4648: needless deadlock on tables having foreign-key

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [Thu, 12 Feb 2009 10:54:34 -0500]:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> > 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.
>
> Read the special code in AfterTriggerSaveEvent. This behavior is
> exactly what is expected --- since the referencing field didn't
> change, only the second update attempt actually fires the trigger.

Why? The second update is identical to the first one.
What is the difference? Such behavior looks very strange.

For example I wrote before to Heikki Linnakangas that I expect
parent tuple will not be lock if
a) foreign key is not modified explicitly at all
b) new value of foreign key is the same as old (not changed).