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
24 matches
Mail list logo
