| From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
|---|---|
| To: | "Greg Stark" <stark(at)enterprisedb(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Michael Cahill" <mjc(at)it(dot)usyd(dot)edu(dot)au>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Serializable Isolation without blocking |
| Date: | 2009-05-08 15:39:43 |
| Message-ID: | 4A040BEF.EE98.0025.0@wicourts.gov |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Greg Stark <stark(at)enterprisedb(dot)com> writes:
>> ... Argh, sorry, as soon as I hit send I realized this is wrong.
>> Writers already need to insert into every index, so that's not a
>> problem.
>
> What about HOT?
I think that a read would need to lock both the row or tuple (not sure
exactly how that would work) and any index used to find the row or
tuple (or detect its absence). If a table scan is used, the lock
would be at the table level (keeping in mind that this is not a lock
which ever blocks anything). An insert or an update which created a
new conflicting tuple would hit the table or index lock. A HOT update
would hit the row lock.
I think....
-Kevin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Seth Robertson | 2009-05-08 15:39:47 | [PATCH] Automatic client certificate selection support for libpq v1 |
| Previous Message | Tom Lane | 2009-05-08 15:30:57 | Re: Serializable Isolation without blocking |