Re: Deadlock bug

Optimized away, check, OK, but why? Because there is no new data in the FK
(table A) at the point of the first update of table B in process 2? But when
process 1 updates A, the FK B->A points to new data, which leads to process
2 tries to acquire a sharelock, which is not granted due to the update of A?

2010/8/20 Tom Lane <tgl@sss.pgh.pa.us>

> Joel Jacobson <joel@gluefinance.com> writes:
> > I fully agree it must obtain a sharelock on the FK, but I cannot
> understand
> > why it is granted it the first time, but not the second time?
>
> It *isn't* granted it the first time, because it doesn't try to acquire
> it the first time.  That FK check gets optimized away, while the second
> one doesn't.  Please reread what I said before.
>
>                        regards, tom lane
>



-- 
Best regards,

Joel Jacobson
Glue Finance

E: jj@gluefinance.com
T: +46 70 360 38 01

Postal address:
Glue Finance AB
Box  549
114 11  Stockholm
Sweden

Visiting address:
Glue Finance AB
Birger Jarlsgatan 14
114 34 Stockholm
Sweden