Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Greenplum
Gpdb
提交
81fd7532
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,发现更多精彩内容 >>
提交
81fd7532
编写于
7月 16, 2000
作者:
P
Peter Eisentraut
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Incorporate README.fsync into main documentation body
上级
b4c315ba
变更
2
隐藏空白更改
内联
并排
Showing
2 changed file
with
34 addition
and
40 deletion
+34
-40
doc/README.fsync
doc/README.fsync
+0
-34
doc/src/sgml/runtime.sgml
doc/src/sgml/runtime.sgml
+34
-6
未找到文件。
doc/README.fsync
已删除
100644 → 0
浏览文件 @
b4c315ba
Fsync() patch (backend -F option)
=================================
Normally, the Postgres'95 backend makes sure that updates are actually
committed to disk by calling the standard function fsync() in
several places. Fsync() should guarantee that every modification to
a certain file is actually written to disk and will not hang around
in write caches anymore. This increases the chance that a database
will still be usable after a system crash by a large amount.
However, this operation severely slows down Postgres'95, because at all
those points it has to wait for the OS to flush the buffers. Especially
in one-shot operations, like creating a new database or loading lots
of data, you'll have a clear restart point if something goes wrong. That's
where the -F option kicks in: it simply disables the calls to fsync().
Without fsync(), the OS is allowed to do its best in buffering, sorting
and delaying writes, so this can be a _very_ big perfomance increase. However,
if the system crashes, large parts of the latest transactions will still hang
around in memory without having been committed to disk - lossage of data
is therefore almost certain to occur.
So it's a tradeoff between data integrity and speed. When initializing a
database, I'd use it - if the machine crashes, you simply remove the files
created and redo the operation. The same goes for bulk-loading data: on
a crash, you remove the database and restore the backup you made before
starting the bulk-load (you always make backups before bulk-loading,
don't you?).
Whether you want to use it in production, is up to you. If you trust your
operating system, your utility company, and your hardware, you might enable
it; however, keep in mind that you're running in an unsecure mode and that
performance gains will very much depend on access patterns (because it won't
help on reading data). I'd recommend against it.
doc/src/sgml/runtime.sgml
浏览文件 @
81fd7532
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.1
4 2000/07/15 21:35:4
7 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.1
5 2000/07/16 14:47:5
7 petere Exp $
-->
<Chapter Id="runtime">
...
...
@@ -846,11 +846,39 @@ env PGOPTIONS='--geqo=off' psql
<term>FSYNC (<type>boolean</type>)</term>
<listitem>
<para>
When this is on (default), an <function>fsync()</function>
call is done after each transaction. Turning this off
increases performance but an operating system crash or power
outage might cause data corruption. (Note that a crash of
<productname>Postgres</productname> itself is not affected.)
If this is option is on, the <productname>Postgres</> backend
will use the <function>fsync()</> system call in several
places to make sure that updates are physically written to
disk and will not hang around in the write caches. This
increases the chance that a database installation will still
be usable after a operating system or hardware crashes by a
large amount. (Crashes of the database server itself do
<emphasis>not</> affect this consideration.)
</para>
<para>
However, this operation severely slows down
<productname>Postgres</>, because at all those points it has
to block and wait for the operating system to flush the
buffers. Without <function>fsync</>, the operating system is
allowed to do its best in buffering, sorting, and delaying
writes, so this can be a <emphasis>very</> big perfomance
increase. However, if the system crashes, parts of the data of
a transaction that has already been committed -- according to
the information on disk -- will still hang around in memory.
Inconsistent data (i.e., data corruption) is therefore likely
to occur.
</para>
<para>
This option is the subject of an eternal debate in the
<productname>Postgres</> user and developer communities. Some
always leave it off, some turn it off only for bulk loads,
where there is a clear restart point if something goes wrong,
some leave it on just to be on the safe side. Because it is
the safe side, on is also the default. If you trust your
operating system, your utility company, and your hardware, you
might want to disable it.
</para>
</listitem>
</varlistentry>
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录