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

Re: A third lock method

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <bruce(at)momjian(dot)us>,"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A third lock method
Date: 2009-12-31 21:53:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
I wrote:
> It's just a little bit of a stretch to call SILOCKs locks, because
> they don't actually block anything. They are used at various points
> to see where a transaction is reading data which has been modified
> by another transaction or vice versa. And they do need to be kept
> until all concurrent transactions have completed. Other than those
> quirks, they behave pretty much like read locks, though, so it
> seems to make sense to use the locking system for them. The
> differences are such that I thought a new lock method might be
> appropriate. This thread is to try to solicit opinions on whether
> that makes sense to anyone but me. :-)
> Once I sort out the subject issue, I'm about ready to try to start
> generating a very rough prototype of predicate locking. I don't
> want to start a discussion of those details on this thread, because
> it seems to me that a decision on the subject issue affects
> significant details about how I go about that.
Based on feedback from Robert Haas on another thread, I think this
thread should be considered wrapped.  It seems to me like SIREAD
locks should be handled by a different lock method, but before I go
there I will probably initially develop and test the predicate
locking logic by using ACCESS EXCLUSIVE locks for all reads, just to
confirm correct coverage of the predicates.
Thanks, all.

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2009-12-31 21:59:01
Subject: Re: Serializable Isolation without blocking
Previous:From: John NaylorDate: 2009-12-31 21:48:52
Subject: Patch v2: Remove all declarations from pg_attribute.h, consolidate BKI scripts

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