On May 21, 2010, at 4:20 , Florian Pflug wrote:
> On May 19, 2010, at 2:15 , Florian Pflug wrote:
>> On May 17, 2010, at 3:30 , Robert Haas wrote:
>>> On Sun, May 16, 2010 at 9:07 PM, Florian Pflug wrote:
On May 14, 2010, at 22:54 , Robert Haas wrote:
> On Thu, May 13, 2010 at 5:39 PM, To
On May 19, 2010, at 2:15 , Florian Pflug wrote:
> On May 17, 2010, at 3:30 , Robert Haas wrote:
>> On Sun, May 16, 2010 at 9:07 PM, Florian Pflug wrote:
>>> On May 14, 2010, at 22:54 , Robert Haas wrote:
On Thu, May 13, 2010 at 5:39 PM, Tom Lane wrote:
> Florian Pflug writes:
>> All
On Tue, May 18, 2010 at 8:15 PM, Florian Pflug wrote:
> Will do. Thanks for the link.
>
> Here is an updated version that works for SHARE locks too.
>
> (This message mainly serves as a way to link the updated patch to the commit
> fest entry. Is this how I'm supposed to do that, or am I doing so
On May 17, 2010, at 3:30 , Robert Haas wrote:
> On Sun, May 16, 2010 at 9:07 PM, Florian Pflug wrote:
>> On May 14, 2010, at 22:54 , Robert Haas wrote:
>>> On Thu, May 13, 2010 at 5:39 PM, Tom Lane wrote:
Florian Pflug writes:
> All in all, I believe that SHARE and UPDATE row-level lock
On Sun, May 16, 2010 at 9:07 PM, Florian Pflug wrote:
> On May 14, 2010, at 22:54 , Robert Haas wrote:
>> On Thu, May 13, 2010 at 5:39 PM, Tom Lane wrote:
>>> Florian Pflug writes:
All in all, I believe that SHARE and UPDATE row-level locks should be
changed to cause concurrent UPDATEs
On May 14, 2010, at 16:32 , Kevin Grittner wrote:
> Florian Pflug wrote:
>
>> I must admit that I wasn't able to find an explicit reference to
>> Oracle's behavior in their docs, so I had to resort to
>> experiments. They do have examples showing how to do FK-like
>> constraints with triggers,
On May 14, 2010, at 22:54 , Robert Haas wrote:
> On Thu, May 13, 2010 at 5:39 PM, Tom Lane wrote:
>> Florian Pflug writes:
>>> All in all, I believe that SHARE and UPDATE row-level locks should be
>>> changed to cause concurrent UPDATEs to fail with a serialization
>>> error.
>>
>> I don't see a
On Sat, May 15, 2010 at 4:09 AM, Kevin Grittner
wrote:
> Anything in particular you wanted me to notice about it besides that?
Nope. It was just a counter point to your previous comment.
--
Rob Wultsch
wult...@gmail.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
Rob Wultsch wrote:
> Have you looked at PBXT (which is explicitly NOT SERIALIZABLE)?
I hadn't heard of it; so I took a quick look based on your post. It
seems to a new engine to use with MySQL which has MVCC without a
rollback log, so it presumably uses techniques at least vaguely
similar to
On Fri, May 14, 2010 at 7:32 AM, Kevin Grittner
wrote:
> Oracle, and all other MVCC databases I've read about outside of PostgreSQL,
> use
> an "update in place with a rollback log" technique.
Have you looked at PBXT (which is explicitly NOT SERIALIZABLE)?
--
Rob Wultsch
wult...@gmail.com
--
On Thu, May 13, 2010 at 5:39 PM, Tom Lane wrote:
> Florian Pflug writes:
>> All in all, I believe that SHARE and UPDATE row-level locks should be
>> changed to cause concurrent UPDATEs to fail with a serialization
>> error.
>
> I don't see an argument for doing that for FOR SHARE locks, and it
>
Florian Pflug wrote:
> I must admit that I wasn't able to find an explicit reference to
> Oracle's behavior in their docs, so I had to resort to
> experiments. They do have examples showing how to do FK-like
> constraints with triggers, and those don't contain any warning
> whatsoever about prob
On May 14, 2010, at 15:54 , Kevin Grittner wrote:
> Florian Pflug wrote:
>> On May 14, 2010, at 12:56 , Kevin Grittner wrote:
>> unless your patch completely removes support for snapshot
>> isolation (what is current called SERIALIZABLE)
>
> Both SERIALIZABLE and REPEATABLE READ currently map to
Florian Pflug wrote:
> On May 14, 2010, at 12:56 , Kevin Grittner wrote:
>> I think that SIREAD locks will generally be cheaper than SELECT
>> FOR UPDATE, since the former don't require any disk I/O and the
>> latter do.
> I can see how a single SIREAD lock can potentially be cheaper than
> a
On May 14, 2010, at 12:56 , Kevin Grittner wrote:
>> True serializable transaction are much more powerful than what I
>> proposed, but at a much higher price too, due to the necessity of
>> SIREAD locks.
>
> I think that SIREAD locks will generally be cheaper than SELECT FOR
> UPDATE, since the fo
[slight rearrangement]
Florian Pflug wrote:
> I'm very exited about the work you're doing
Always nice to hear. :-)
> I view my proposal as pretty orthogonal to that work.
> My proposal allows for simple FK-like constraints to be
> implemented at user-level that are correct for all isola
On May 14, 2010, at 2:37 , Greg Stark wrote:
> On Thu, May 13, 2010 at 10:25 PM, Florian Pflug wrote:
>> C1: BEGIN
>> C1: SELECT * FROM t WHERE id = 1 FOR UPDATE
>> C2: BEGIN
>> C2: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
>> C2: SELECT * FROM t -- Take snapshot before C1 commits
>> C1: COMM
2010/5/14 Greg Stark :
> On Thu, May 13, 2010 at 10:25 PM, Florian Pflug wrote:
>
>> C1: BEGIN
>> C1: SELECT * FROM t WHERE id = 1 FOR UPDATE
>> C2: BEGIN
>> C2: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
>> C2: SELECT * FROM t -- Take snapshot before C1 commits
>> C1: COMMIT
>> C2: DELETE FROM
On 05/14/2010 03:37 AM, Greg Stark wrote:
> On Thu, May 13, 2010 at 10:25 PM, Florian Pflug wrote:
>> C1: BEGIN
>> C1: SELECT * FROM t WHERE id = 1 FOR UPDATE
>> C2: BEGIN
>> C2: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
>> C2: SELECT * FROM t -- Take snapshot before C1 commits
>> C1: COMMIT
>
On Thu, May 13, 2010 at 10:25 PM, Florian Pflug wrote:
> C1: BEGIN
> C1: SELECT * FROM t WHERE id = 1 FOR UPDATE
> C2: BEGIN
> C2: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
> C2: SELECT * FROM t -- Take snapshot before C1 commits
> C1: COMMIT
> C2: DELETE FROM t WHERE id = 1
> C2: COMMIT
>
Can
On May 13, 2010, at 23:51 , Kevin Grittner wrote:
> Florian Pflug wrote:
>
>> All in all, I believe that SHARE and UPDATE row-level locks should
>> be changed to cause concurrent UPDATEs to fail with a
>> serialization error. I can come up with a patch that does that,
>> but I wanted to get som
On May 13, 2010, at 23:39 , Tom Lane wrote:
> Florian Pflug writes:
>> All in all, I believe that SHARE and UPDATE row-level locks should be
>> changed to cause concurrent UPDATEs to fail with a serialization
>> error.
>
> I don't see an argument for doing that for FOR SHARE locks, and it
> alrea
Florian Pflug wrote:
> All in all, I believe that SHARE and UPDATE row-level locks should
> be changed to cause concurrent UPDATEs to fail with a
> serialization error. I can come up with a patch that does that,
> but I wanted to get some feedback on the idea before I put the
> work in.
Before
Florian Pflug writes:
> All in all, I believe that SHARE and UPDATE row-level locks should be
> changed to cause concurrent UPDATEs to fail with a serialization
> error.
I don't see an argument for doing that for FOR SHARE locks, and it
already happens for FOR UPDATE (at least if the row actually
Hi
After the recent discussion about the impossibility of efficiently implementing
FK-like constraint triggers in PL/PGSQL that work correctly under SERIALIZABLe
transactions, I've compared our behavior to that of Oracle. As it turns out, a
slight difference in Oracle's behavior makes those FK
How do we acquire row level locks in postgresql and is there any feild in
LOCK or PROCLOCK datastructes (src/include/storage/lock.h) that tells us the
lock is row-level?
thanks
_
Enter for your chance to IM with Bon Jovi, Seal, Bow
How do we acquire row level locks and is there a way to detect them from the any of lock data structures (like Lock, ProcLock, PGPROCK, and LockData)?
thanks
jennyThe new MSN 8: smart spam protection and 2 months FREE*
On the documentation
http://www.postgresql.org/users-lounge/docs/7.0/postgres/mvcc4646.htm what
does mean "...Postgres doesn't remember any information about modified rows
in memory and so has no limit to the number of rows locked without lock
escalation."?
Following you find "How
28 matches
Mail list logo
