Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Greenplum
Gpdb
提交
fb4f5f7c
G
Gpdb
项目概览
Greenplum
/
Gpdb
通知
7
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
Gpdb
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
fb4f5f7c
编写于
6月 03, 1999
作者:
V
Vadim B. Mikheev
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Notes in Migration to v6.5 section.
上级
9680a712
变更
2
隐藏空白更改
内联
并排
Showing
2 changed file
with
57 addition
and
3 deletion
+57
-3
doc/src/sgml/mvcc.sgml
doc/src/sgml/mvcc.sgml
+1
-1
doc/src/sgml/release.sgml
doc/src/sgml/release.sgml
+56
-2
未找到文件。
doc/src/sgml/mvcc.sgml
浏览文件 @
fb4f5f7c
...
...
@@ -515,7 +515,7 @@ ERROR: Can't serialize access due to concurrent update
by <command>SELECT</command> it doesn't mean that this row really
exists at the time it is returned (i.e. sometime after the
statement or transaction began) nor
that the row is protected from deletion or updat
e
by concurrent
that the row is protected from deletion or updat
ion
by concurrent
transactions before the current transaction does a commit or rollback.
</para>
...
...
doc/src/sgml/release.sgml
浏览文件 @
fb4f5f7c
...
...
@@ -132,11 +132,65 @@
is required for those wishing to migrate data from any
previous release of <productname>Postgres</productname>.
</para>
</sect2>
<para>
Because readers in 6.5 don't lock data, regardless of transaction
isolation level, data read by one transaction can be overwritten by
another. In the other words, if a row is returned by
<command>SELECT</command> it doesn't mean that this row really exists
at the time it is returned (i.e. sometime after the statement or
transaction began) nor that the row is protected from deletion or
updation by concurrent transactions before the current transaction does
a commit or rollback.
</para>
<para>
To ensure the actual existance of a row and protect it against
concurrent updates one must use <command>SELECT FOR UPDATE</command> or
an appropriate <command>LOCK TABLE</command> statement. This should be
taken into account when porting applications from previous releases of
<productname>Postgres</productname> and other environments.
</para>
<para>
Keep above in mind if you are using contrib/refint.* triggers for
referential integrity. Additional technics are required now. One way is
to use <command>LOCK parent_table IN SHARE ROW EXCLUSIVE MODE</command>
command if a transaction is going to update/delete a primary key and
use <command>LOCK parent_table IN SHARE MODE</command> command if a
transaction is going to update/insert a foreign key.
<note>
<para>
Note that if you run a transaction in SERIALIZABLE mode then you must
execute <command>LOCK</command> commands above before execution of any
DML statement
(<command>SELECT/INSERT/DELETE/UPDATE/FETCH/COPY_TO</command>) in the
transaction.
</para>
</note>
<para>
These inconveniences will disappear when the ability to read durty
(uncommitted) data, regardless of isolation level, and true referential
integrity will be implemented.
</para>
</para>
</sect2>
<sect2>
<title>Detailed Change List</title>
<para>
<programlisting>
Bug Fixes
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录