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
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 |