From: | Ed Loehr <eloehr(at)austin(dot)rr(dot)com> |
---|---|
To: | Joachim Achtzehnter <joachim(at)kraut(dot)bc(dot)ca> |
Cc: | pgsql-general(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Revisited: Transactions, insert unique. |
Date: | 2000-04-26 16:59:46 |
Message-ID: | 39072082.CFBB6F9D@austin.rr.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Joachim Achtzehnter wrote:
>
> In a message to Ed Loehr and pgsql-general, Lincoln Yeoh wrote:
> >
> > Transaction A
> > begin;
> > insert into test (a,b) select 4,'four' from test
> > where not exists (select * from test where a=4);
> >
> > Transaction B
> > begin;
> > insert into test (a,b) select 4,'four' from test
> > where not exists (select * from test where a=4);
> >
> > Then you do a commit on both, and you end up with two rows.
>
> This is dissapointing indeed! What this means is that Postgresql
> transactions are, in fact, not truely serializable. The concurrent
> execution of these two transactions is not equivalent to some serial
> execution.
>
> Have to read up on the documentation, which I thought was claiming
> serializability.
Hmmm. This surprised me, too. The serialization doesn't work as I
expected it to. Maybe someone can illuminate. Here's what confused me...
The documentation says:
Serializable provides the highest transaction isolation.
When a transaction is on the serializable level, a query
sees only data committed before the transaction began and
never see either dirty data or concurrent transaction
changes committed during transaction execution. So, this
level emulates serial transaction execution, as if
transactions would be executed one after another, serially,
rather than concurrently.
- http://www.postgresql.org/docs/postgres/mvcc4508.htm (4/25/2000)
But the following sequence seems to contradict this:
-- Transaction A
DROP TABLE foo;
CREATE TABLE foo (id INTEGER);
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;
-- Transaction B
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;
INSERT INTO foo (id) SELECT 1 WHERE NOT EXISTS (SELECT * FROM foo WHERE id
= 1);
COMMIT;
SELECT * FROM foo;
-- Transaction A
SELECT * FROM foo;
INSERT INTO foo (id) SELECT 1 WHERE NOT EXISTS (SELECT * FROM foo WHERE id
= 1);
SELECT * FROM foo;
COMMIT;
This sequence allows B's inserts, AFTER A began, to be seen by A (at least,
in pgsql 7.0beta3).
Anyone understand what's going on here? Bug?
Regards,
Ed Loehr
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Mercer | 2000-04-26 17:22:11 | pgsql/php3/apache authentication |
Previous Message | Jan Wieck | 2000-04-26 16:58:20 | Re: unique row identifier data type exhausted . . . |