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

Commite76cbb6

Browse files
committed
Reword overly-optimistic comment about backup checksum verification.
The comment implies that a single retry is sufficient to avoidspurious checksum failures, but in fact no number of retries issufficient for that purpose. Update the comment accordingly.Patch by me, reviewed by Michael Paquier.Discussion:http://postgr.es/m/CA+TgmoZ_fFAoU6mrHt9QBs+dcYhN6yXenGTTMRebZNhtwPwHyg@mail.gmail.com
1 parentf3948b5 commite76cbb6

File tree

1 file changed

+15
-5
lines changed

1 file changed

+15
-5
lines changed

‎src/backend/backup/basebackup.c

Lines changed: 15 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1602,11 +1602,21 @@ sendFile(bbsink *sink, const char *readfilename, const char *tarfilename,
16021602
* Retry the block on the first failure. It's
16031603
* possible that we read the first 4K page of the
16041604
* block just before postgres updated the entire block
1605-
* so it ends up looking torn to us. We only need to
1606-
* retry once because the LSN should be updated to
1607-
* something we can ignore on the next pass. If the
1608-
* error happens again then it is a true validation
1609-
* failure.
1605+
* so it ends up looking torn to us. If, before we
1606+
* retry the read, the concurrent write of the block
1607+
* finishes, the page LSN will be updated and we'll
1608+
* realize that we should ignore this block.
1609+
*
1610+
* There's no guarantee that this will actually
1611+
* happen, though: the torn write could take an
1612+
* arbitrarily long time to complete. Retrying multiple
1613+
* times wouldn't fix this problem, either, though
1614+
* it would reduce the chances of it happening in
1615+
* practice. The only real fix here seems to be to
1616+
* have some kind of interlock that allows us to wait
1617+
* until we can be certain that no write to the block
1618+
* is in progress. Since we don't have any such thing
1619+
* right now, we just do this and hope for the best.
16101620
*/
16111621
if (block_retry== false)
16121622
{

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp