Re: Read Uncommitted
От | Koichi Suzuki |
---|---|
Тема | Re: Read Uncommitted |
Дата | |
Msg-id | a778a7260805260511y3166f76dt68adcd967294cb8d@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Read Uncommitted (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>) |
Ответы |
Re: Read Uncommitted
|
Список | pgsql-hackers |
Hi, Because Read Uncommitted shows all the "yet not committed" version, it seems to me that there's no problem to show the new version of tuples to Read Uncommitted transacations as follows: SQLs (old version) (new version) -------------------+----------------------------+------------------------------ INSERT none new tuple UPDATE old tupe new tuple DELETE old tuple none If update transaction fails, then new version is invalid and the old version should be shown to Read Uncomitted transcactions. Therefore, there're no Read Committed or Serializable transactions which refers to old version tuples, it could be thought that old version can be vacuumed or swept. Obviously, to "read committed" transactions, old version has to be shown. Any advices? 2008/5/26 ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>: > > Simon Riggs <simon@2ndquadrant.com> wrote: > >> The use of this is clear though: allowing long running transactions >> against unchanging data to not interfere with other activities. It will >> also have importance in a Hot Standby mode. > > I have an use of the dirty read -- pg_start_backup(). > In 8.3, pg_start_backup takes long time, that is typically > { checkpoint_timeout * checkpoint_completion_target }. > > If we have some updating transaction during pg_start_backup, > updated tables cannot be vacuumed well. READ UNCOMMITTED mode > could help us in such a situation. > > BEGIN; > SET TRANSACTION READ UNCOMMITTED; > SELECT pg_start_backup(timeofday()); > END; > > Regards, > --- > ITAGAKI Takahiro > NTT Open Source Software Center > > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- ------ Koichi Suzuki
В списке pgsql-hackers по дате отправления: