I can't reproduce the above. Are you sure T2 isn't committing?
Arch, damn, yes, bugger...
If it were, since the default isolation level is read committed,
Ok, that explains it.
But my second question is still unanswered: Is the key value locking, that
is implemented in postgres, ARIES/KVL?
Rasmus Resen Amossen wrote:
> Does Postgres garantee repeatable-read (RR) during transactions? And
> does it implement ARIES/KVL?
>
> If so, why is the following possible?
>
> T1: begin;
> T1: select * from table;
> (notice the row with id = X)
> T2: begin;
> T2: delete from table where id = X
I wrote:
> Rasmus Resen Amossen wrote:
>
>
>>Does Postgres garantee repeatable-read (RR) during transactions? And
>>does it implement ARIES/KVL?
>>
>>If so, why is the following possible?
>>
>>T1: begin;
>>T1: select * from table;
>> (notice the row with id = X)
>>T2: begin;
>>T2: delete from t
I'm moving this to GENERAL. Whomsoever replies there please delete the
pgsql-hackers cc entry.
On Thu, 5 Jun 2003, Rasmus Resen Amossen wrote:
> Does Postgres garantee repeatable-read (RR) during transactions? And does it
> implement ARIES/KVL?
>
> If so, why is the following possible?
>
> T
> T1: begin;
> T1: select * from table;
>(notice the row with id = X)
> T2: begin;
> T2: delete from table where id = X;
> T1: select * from table;
>(notice the row with id = X suddenly is gone)
You'll need to SELECT ... FOR UPDATE to lock the row, or use the
SERIALIZABLE transaction more
On Thu, 5 Jun 2003, Rasmus Resen Amossen wrote:
> Does Postgres garantee repeatable-read (RR) during transactions? And does it
> implement ARIES/KVL?
>
> If so, why is the following possible?
>
> T1: begin;
> T1: select * from table;
>(notice the row with id = X)
> T2: begin;
> T2: delete fro
