RE: [HACKERS] READ COMMITTED isolevel is implemented ...

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Vadim Mikheev" <vadim(at)krs(dot)ru>, <hackers(at)postgreSQL(dot)org>
Subject: RE: [HACKERS] READ COMMITTED isolevel is implemented ...
Date: 1999-01-30 00:05:24
Message-ID: 000301be4be4$3c4c1b80$2801007e@cadzone.tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello All,

> -----Original Message-----
> From: owner-pgsql-hackers(at)postgreSQL(dot)org
> [mailto:owner-pgsql-hackers(at)postgreSQL(dot)org]On Behalf Of Vadim Mikheev
> Sent: Saturday, January 30, 1999 2:55 AM
> To: hackers(at)postgreSQL(dot)org
> Subject: [HACKERS] READ COMMITTED isolevel is implemented ...
>
>
> and this is now the DEFAULT isolevel.
>

It's different from current(v6.4.2).
The way will be provided to upgrade user's current code ?

> I run some tests to ensure how it works, but not so much.
> Unfortunately, currently it's not possible to add
> such tests to regression suit because of they require
> concurrent transactions. We could write simple script to
> run a few psql-s simultaneously and than just put queries
> to them (through pipes) in required order. I have no time
> for this now...
>
> Processing updates in READ COMMITTED isolevel is much
> complex than in SERIALIZABLE one, because of if transaction T1
> notices that tuple to be updated/deleted/selected_for_update
> is changed by concurrent transaction T2 then T1 has to check
> does new version of tuple satisfy T1 plan qual or not.

How about UPDATE t set x = x + 1 where .... ?

The values of x used for x = x + 1 are at the time when statement
started ?
It seems that this case also requires re-execution.

Thanks.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 1999-01-30 01:18:52 Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed)
Previous Message Jan Wieck 1999-01-29 22:10:35 Re: [HACKERS] Postgres Speed or lack thereof