| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Rod Taylor <rbt(at)rbt(dot)ca> |
| Cc: | sailesh(at)cs(dot)berkeley(dot)edu, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Jenny - <nat_lazy(at)hotmail(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: this is in plain text (row level locks) |
| Date: | 2003-07-24 13:36:23 |
| Message-ID: | 17653.1059053783@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Rod Taylor <rbt(at)rbt(dot)ca> writes:
> 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.
Hmm, that might be workable. We could imagine that in place of the
HEAP_MARKED_FOR_UPDATE status bit, we have a "this row is possibly
locked" hint bit. Only if you see the bit set do you need to query
the lock manager. If the answer comes back that no lock is held,
you can clear the bit --- so no need for any painful "undo" stuff
after a crash, and no communication overhead in the normal case.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Francisco Figueiredo Jr. | 2003-07-24 13:51:00 | Re: Why select * from function doesn't work when function |
| Previous Message | Lee Kindness | 2003-07-24 13:12:04 | Re: libpq_r |