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>> 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.comT: +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