| From: | "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
|---|---|
| To: | "Kevin Grittner *EXTERN*" <Kevin(dot)Grittner(at)wicourts(dot)gov>, <robertmhaas(at)gmail(dot)com> |
| Cc: | <nicolas(dot)barbier(at)gmail(dot)com>, <gsstark(at)mit(dot)edu>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Serializable Isolation without blocking |
| Date: | 2010-01-01 18:16:19 |
| Message-ID: | D960CB61B694CF459DCFB4B0128514C203A89940@exadv11.host.magwien.gv.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Kevin Grittner wrote:
>> It seems to me that the hard part of this problem is to describe
>> the general mechanism by which conflicts will be detected, with
>> specific references to the types of data structures that will be
>> used to hold that information.
>
> Well, the general approach to tracking SIREAD locks I had in mind is
> to keep them in the existing lock data structures.
> [...]
If I remember right, one necessity for the SIREAD lock technique was
that SIREAD locks taken by a transaction have to be kept after the
transaction has ended.
Won't that require fundamental changes?
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2010-01-01 18:39:52 | Re: Cancelling idle in transaction state |
| Previous Message | Robert Haas | 2010-01-01 18:15:14 | Re: Cancelling idle in transaction state |