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 <t...@sss.pgh.pa.us>

> Joel Jacobson <j...@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: j...@gluefinance.com
T: +46 70 360 38 01

Postal address:
Glue Finance AB
Box  549
114 11  Stockholm

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

Reply via email to