Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Greenplum
Gpdb
提交
9b2c14cf
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,发现更多精彩内容 >>
提交
9b2c14cf
编写于
6月 22, 2010
作者:
R
Robert Haas
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Minor markup improvements for Hot Standby documentation.
上级
2e8a832d
变更
2
隐藏空白更改
内联
并排
Showing
2 changed file
with
19 addition
and
19 deletion
+19
-19
doc/src/sgml/config.sgml
doc/src/sgml/config.sgml
+9
-9
doc/src/sgml/high-availability.sgml
doc/src/sgml/high-availability.sgml
+10
-10
未找到文件。
doc/src/sgml/config.sgml
浏览文件 @
9b2c14cf
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.28
1 2010/06/15 07:52:10 itagaki
Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.28
2 2010/06/22 02:57:49 rhaas
Exp $ -->
<chapter Id="runtime-config">
<title>Server Configuration</title>
...
...
@@ -1977,14 +1977,14 @@ SET ENABLE_SEQSCAN TO OFF;
<acronym>HOT</> updates will defer cleanup of dead row versions. The
default is 0 transactions, meaning that dead row versions will be
removed as soon as possible. You may wish to set this to a non-zero
value when planning or maintaining a
<xref linkend="hot-standby">
configuration. The recommended value is <literal>0</> unless you have
clear reason to increase it. The purpose of the parameter is to
allow the user to specify an approximate time delay before cleanup
occurs. However, it should be noted that there is no direct link with
any specific time delay and so the results will be application and
installation specific, as well as variable over time, depending upon
the transaction rate (of writes only).
value when planning or maintaining a
Hot Standby connection, as
described in <xref linkend="hot-standby">. The recommended value is
<literal>0</> unless you have clear reason to increase it. The purpose
of the parameter is to allow the user to specify an approximate time
delay before cleanup occurs. However, it should be noted that there is
no direct link with any specific time delay and so the results will be
application and installation specific, as well as variable over time,
depending upon
the transaction rate (of writes only).
</para>
</listitem>
</varlistentry>
...
...
doc/src/sgml/high-availability.sgml
浏览文件 @
9b2c14cf
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.7
3 2010/06/11 10:13:08 heikki
Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.7
4 2010/06/22 02:57:50 rhaas
Exp $ -->
<chapter id="high-availability">
<title>High Availability, Load Balancing, and Replication</title>
...
...
@@ -1330,7 +1330,7 @@ if (!triggered)
</listitem>
<listitem>
<para>
LISTEN, UNLISTEN, NOTIFY
<command>LISTEN</>, <command>UNLISTEN</>, <command>NOTIFY</>
</para>
</listitem>
</itemizedlist>
...
...
@@ -1437,14 +1437,14 @@ if (!triggered)
Some WAL redo actions will be for <acronym>DDL</> execution. These DDL
actions are replaying changes that have already committed on the primary
node, so they must not fail on the standby node. These DDL locks take
priority and will automatically
*cancel* any read-only transactions that
get in their way, after a grace period. This is similar to the possibility
of being canceled by the deadlock detector. But in this case, the standby
recovery process always wins, since the replayed actions must not fail.
This also ensures that replication does not fall behind while waiting for a
query to complete. This prioritization presumes that the standby exists
primarily for high availability, and that adjusting the grace period
will allow a sufficient guard against unexpected cancellation.
priority and will automatically
<emphasis>cancel</> any read-only
transactions that get in their way, after a grace period. This is similar
to the possibility of being canceled by the deadlock detector. But in this
case, the standby recovery process always wins, since the replayed actions
must not fail. This also ensures that replication does not fall behind
while waiting for a query to complete. This prioritization presumes that
the standby exists primarily for high availability, and that adjusting the
grace period
will allow a sufficient guard against unexpected cancellation.
</para>
<para>
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录