On Thu, 2003-07-24 at 02:45, Sailesh Krishnamurthy wrote:
> >>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>
> Tom> That doesn't work, unless you insist that the first backend
> Tom> can't exit its transaction until all the other ones are done.
> Tom> Which introduces its own possibilities for deadlock --- but
> Tom> even worse, how does the first backend *know* that the other
> Tom> ones are done? You're right back where you started: it has
> Tom> to be possible to tell which backends have share-locked a
> Tom> particular row.
>
> Is a count a solution ?
Almost. Problem with a count is the difficulty decrementing the count
after a crash. You would also need to store a log of some kind so you
know what to reset while starting up in error recovery mode which would
add a large amount of overhead.
It may be best to have a locking manager run as a separate process.
That way it could store locks in ram or spill over to disk. Now the
problem is communication overhead. It probably isn't any worse than
writing them to disk for long queries (actual disk activity resulting),
but short queries are probably going to notice.