| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | nicolas(dot)barbier(at)gmail(dot)com, gsstark(at)mit(dot)edu, pgsql-hackers(at)postgresql(dot)org, laurenz(dot)albe(at)wien(dot)gv(dot)at |
| Subject: | Re: Serializable Isolation without blocking |
| Date: | 2010-01-01 00:31:24 |
| Message-ID: | 603c8f070912311631v1b10b662i8065e81f21d68b81@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Dec 31, 2009 at 4:44 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> I wonder if you couldn't start with something ridiculously poor,
>> like maybe an S2PL implementation with only table-level granularity
>> - just make any operation that reads or writes a table grab an
>> ACCESS EXCLUSIVE lock until transaction commit.
>
> There's an idea I hadn't thought of -- doing S2PL but with ACCESS
> EXCLUSIVE locks for the read locks to test the predicate locking. It
> would let me play around with testing that phase before I moved to
> the next with minimal wasted effort.
What predicate locking? If you take ACCESS EXCLUSIVE locks on every
read, that should serialize all access to every table. Predicate
locking wouldn't do anything, because the table would be completely
inaccessible to all competing transactions.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2010-01-01 00:45:37 | Re: Serializable Isolation without blocking |
| Previous Message | Robert Haas | 2010-01-01 00:24:09 | Re: PATCH: Add hstore_to_json() |