On Thu, 2003-07-24 at 02:45, Sailesh Krishnamurthy wrote: > >>>>> "Tom" == Tom Lane <[EMAIL PROTECTED]> 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.
signature.asc
Description: This is a digitally signed message part
