Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Greenplum
Gpdb
提交
9df56f6d
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,发现更多精彩内容 >>
提交
9df56f6d
编写于
3月 22, 2013
作者:
S
Simon Riggs
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Add new README file for pages/checksums
上级
96ef3b8f
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
52 addition
and
0 deletion
+52
-0
src/backend/storage/page/README
src/backend/storage/page/README
+52
-0
未找到文件。
src/backend/storage/page/README
0 → 100644
浏览文件 @
9df56f6d
src/backend/storage/page/README
Checksums
---------
Checksums on data pages are designed to detect corruption by the I/O system.
We do not protect buffers against uncorrectable memory errors, since these
have a very low measured incidence according to research on large server farms,
http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf, discussed
2010/12/22 on -hackers list.
Current implementation requires this be enabled system-wide at initdb time.
The checksum is not valid at all times on a data page!!
The checksum is valid when the page leaves the shared pool and is checked
when it later re-enters the shared pool as a result of I/O.
We set the checksum on a buffer in the shared pool immediately before we
flush the buffer. As a result we implicitly invalidate the page's checksum
when we modify the page for a data change or even a hint. This means that
many or even most pages in shared buffers have invalid page checksums,
so be careful how you interpret the pd_checksum field.
That means that WAL-logged changes to a page do NOT update the page checksum,
so full page images may not have a valid checksum. But those page images have
the WAL CRC covering them and so are verified separately from this
mechanism. WAL replay should not test the checksum of a full-page image.
The best way to understand this is that WAL CRCs protect records entering the
WAL stream, and data page verification protects blocks entering the shared
buffer pool. They are similar in purpose, yet completely separate. Together
they ensure we are able to detect errors in data re-entering
PostgreSQL-controlled memory. Note also that the WAL checksum is a 32-bit CRC,
whereas the page checksum is only 16-bits.
Any write of a data block can cause a torn page if the write is unsuccessful.
Full page writes protect us from that, which are stored in WAL. Setting hint
bits when a page is already dirty is OK because a full page write must already
have been written for it since the last checkpoint. Setting hint bits on an
otherwise clean page can allow torn pages; this doesn't normally matter since
they are just hints, but when the page has checksums, then losing a few bits
would cause the checksum to be invalid. So if we have full_page_writes = on
and checksums enabled then we must write a WAL record specifically so that we
record a full page image in WAL. Hint bits updates should be protected using
MarkBufferDirtyHint(), which is responsible for writing the full-page image
when necessary.
New WAL records cannot be written during recovery, so hint bits set during
recovery must not dirty the page if the buffer is not already dirty, when
checksums are enabled. Systems in Hot-Standby mode may benefit from hint bits
being set, but with checksums enabled, a page cannot be dirtied after setting a
hint bit (due to the torn page risk). So, it must wait for full-page images
containing the hint bit updates to arrive from the master.
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录