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 f...@phlo.org wrote:
On May 14, 2010, at 22:54 , Robert Haas wrote:
On Thu, May 13, 2010 at 5:39 PM, Tom
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 f...@phlo.org wrote:
On May 14, 2010, at 22:54 , Robert Haas wrote:
On Thu, May 13, 2010 at 5:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug
On May 17, 2010, at 3:30 , Robert Haas wrote:
On Sun, May 16, 2010 at 9:07 PM, Florian Pflug f...@phlo.org wrote:
On May 14, 2010, at 22:54 , Robert Haas wrote:
On Thu, May 13, 2010 at 5:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org writes:
All in all, I believe that
On Tue, May 18, 2010 at 8:15 PM, Florian Pflug f...@phlo.org 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
On May 14, 2010, at 22:54 , Robert Haas wrote:
On Thu, May 13, 2010 at 5:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org 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.
On May 14, 2010, at 16:32 , Kevin Grittner wrote:
Florian Pflug f...@phlo.org 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
On Sun, May 16, 2010 at 9:07 PM, Florian Pflug f...@phlo.org wrote:
On May 14, 2010, at 22:54 , Robert Haas wrote:
On Thu, May 13, 2010 at 5:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org writes:
All in all, I believe that SHARE and UPDATE row-level locks should be
On Fri, May 14, 2010 at 7:32 AM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
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 Sat, May 15, 2010 at 4:09 AM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
2010/5/14 Greg Stark gsst...@mit.edu:
On Thu, May 13, 2010 at 10:25 PM, Florian Pflug f...@phlo.org 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 May 14, 2010, at 2:37 , Greg Stark wrote:
On Thu, May 13, 2010 at 10:25 PM, Florian Pflug f...@phlo.org 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:
[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
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 former
Florian Pflug f...@phlo.org 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
On May 14, 2010, at 15:54 , Kevin Grittner wrote:
Florian Pflug f...@phlo.org 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
Florian Pflug f...@phlo.org 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
On Thu, May 13, 2010 at 5:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org 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
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
Florian Pflug f...@phlo.org 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
Florian Pflug f...@phlo.org 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.
On May 13, 2010, at 23:39 , Tom Lane wrote:
Florian Pflug f...@phlo.org 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
On May 13, 2010, at 23:51 , Kevin Grittner wrote:
Florian Pflug f...@phlo.org 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
On Thu, May 13, 2010 at 10:25 PM, Florian Pflug f...@phlo.org 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
On 05/14/2010 03:37 AM, Greg Stark wrote:
On Thu, May 13, 2010 at 10:25 PM, Florian Pflugf...@phlo.org 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
25 matches
Mail list logo
