Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commita4b94b8

Browse files
README comments on checksums on page holes.
1 parent1be2035 commita4b94b8

File tree

1 file changed

+11
-0
lines changed
  • src/backend/storage/page

1 file changed

+11
-0
lines changed

‎src/backend/storage/page/README

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -44,6 +44,17 @@ record a full page image in WAL. Hint bits updates should be protected using
4444
MarkBufferDirtyHint(), which is responsible for writing the full-page image
4545
when necessary.
4646

47+
Note that when we write a page checksum we include the hopefully zero bytes
48+
that form the hole in the centre of a standard page. Thus, when we read the
49+
block back from storage we implicitly check that the hole is still all zeroes.
50+
We do this to ensure that we spot errors that could have destroyed data even
51+
if they haven't actually done so. Full page images stored in WAL do *not*
52+
check that the hole is all zero; the data in the hole is simply skipped and
53+
re-zeroed if the backup block is reapplied. We do this because a failure in
54+
WAL is a fatal error and prevents further recovery, whereas a checksum failure
55+
on a normal data block is a hard error but not a critical one for the server,
56+
even if it is a very bad thing for the user.
57+
4758
New WAL records cannot be written during recovery, so hint bits set during
4859
recovery must not dirty the page if the buffer is not already dirty, when
4960
checksums are enabled. Systems in Hot-Standby mode may benefit from hint bits

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp