Skip site navigation (1) Skip section navigation (2)

Re: Serializable Isolation without blocking

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <gsstark(at)mit(dot)edu>
Cc: <nicolas(dot)barbier(at)gmail(dot)com>,<robertmhaas(at)gmail(dot)com>, <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:18:02
Message-ID: 4B3CEADA020000250002DC09@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
Greg Stark  wrote:
 
> aaah... I think I see where we've gone off track in previous
> discussions...you think postgres keeps row level locks in a shared
> memory data structure. It doesn't it stores all row level locks
> *in* the tuple itself. It only stores the lock in memory briefly
> while actually acquiring the lock. Once it acquires it the only
> record of the lock is the xid in the tuple itself.
 
> This means there are no memory limits on the number of records
> locked by a transaction.
 
> storing the lock data in the tuples won't work for you at all
> because you need to lock rows that don't exist yet at all.that's
> why "where to store the lock" is a critical blocking issue to
> figure out to know whether the plan is feasible at all.
 
I'm probably not quite as clueless as you think on this; I realize
that keeping SIREAD locks in memory will require many more slots for
locks, escalation from tuple level to page or coarser when there are
many on a table, or (most likely) both.  Please have patience while I
try to work out the details; until I get a bit farther, everyone will
be spinning their wheels if we try to get too far into details -- it
will all be speculation and/or hand-waving, with much mayhem to straw
men.
 
This much is fairly firm in my head, so I probably should share:
 
What I do think is that the structures for regular locks seem usable
to track the information I need without having to burden read
operations with disk output, which I see as absolutely necessary for
adequate performance.  It also gives me somewhere to store locks
related to search ranges where data doesn't currently exist, and the
ability to store read locks from many transactions against the same
data.
 
An open question in my mind is whether I might need to keep write
locks for serializable transactions in the shared memory lock hash
table until commit or rollback; I rather suspect that I will, with
similar granularity escalation policies.  That's likely to raise a
hue and cry, but like I've said before -- I won't try to force
anybody to use this, and the structures involved are of reasonable
size to allow using many of them.  I suppose these more persistent
write locks should be kept out of the DEFAULT lock method, too....
 
Thanks, and Happy New Year!
 
-Kevin

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-01-01 00:24:09
Subject: Re: PATCH: Add hstore_to_json()
Previous:From: David E. WheelerDate: 2009-12-31 23:54:31
Subject: Re: Group and Role Disagreement

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group