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 pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073