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(at)sss(dot)pgh(dot)pa(dot)us>

> Joel Jacobson <joel(at)gluefinance(dot)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(at)gluefinance(dot)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