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 Sweden Visiting address: Glue Finance AB Birger Jarlsgatan 14 114 34 Stockholm Sweden
