From: | Vadim Mikheev <vadim(at)krs(dot)ru> |
---|---|
To: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
Cc: | hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] READ COMMITTED isolevel is implemented ... |
Date: | 1999-01-30 04:40:36 |
Message-ID: | 36B28D44.F2F6718C@krs.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hiroshi Inoue wrote:
>
> > Subject: [HACKERS] READ COMMITTED isolevel is implemented ...
> >
> > and this is now the DEFAULT isolevel.
> >
>
> It's different from current(v6.4.2).
First, I think that DEFAULT isolevel must be configure-able.
> The way will be provided to upgrade user's current code ?
Even SERIALIZABLE isolevel in MVCC is different from
one in locking systems. There is only one way to don't
change anything in applications - use table level locking.
Should we provide ability to turn MVCC off?
> > 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.
x + 1 is in target list of execution plan. And so when child plan
is executed, new value of x is used to evaluate target list
expressions. Executor uses tuple from child plan as new version
of tuple.
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-01-30 05:13:47 | Re: AW: [HACKERS] Another TEMP table trick |
Previous Message | Charles Hornberger | 1999-01-30 04:20:17 | Re: [GENERAL] nested loops in joins, ambiguous rewrite rules |