Richard Huxton wrote: > Christopher Kings-Lynne wrote: > >> Uh ... the interesting question is usually not "does this backend hold > >> any row locks", it is "is this row locked by any backends". If the > >> latter question is not *exceedingly* cheap to answer, at least in the > >> normal case where the answer is no, you don't have a workable solution, > >> because you'll be adding nontrivial overhead to every row update. > > > > > > OK, what I mean is to know if a row is locked by any backend, why can't > > we just put a reference count of the number of locks on that row, > > instead of recording each backend separately? Wouldn't that require a > > fixed amount of shared mem? > > Don't forget having to deal with a backend dying without being able to > decrement the count (not my idea, Bruce (iirc) mentioned it last time > this was discussed). I think at the least you'd need a > max-trans-id-with-lock number stored next to the count so that in the > event of backend crashes the lock will eventually be released.
Even more significantly, how does the backend know where to go to decrement its row counts on commit? I think the best we could do would be to store the xids on the row for each backend that has a shared lock. The list could be cleared out automatically by looking in the PROC structure and removing completed xids. However, that is a lot of storage for each row to have and a centralized table is probably best where backends can clean up on their own on commit. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
