forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commitacf1dd4
committed
Don't retry restore_command while reading ahead.
Suppress further attempts to read ahead in the WAL if we run out ofdata, until the records already decoded have been replayed. Thisrestores the traditional behavior for continuous archive recovery, whichis to retry the failing restore_command only every 5 seconds. With thecoding in5dc0418, we would start retrying every time through therecovery loop when our WAL decoding window hit the end of the currentsegment and we tried to look ahead into a not-yet-available next file.That was very slow.Also change the no_readahead_until mechanism to use <= rather than <,which seems more useful. Otherwise we'd either get one extra unwantedretry of restore_command, or we'd need to add 1 to an LSN.No change in behavior for regular streaming. That was already limitedby the flushedUpto variable, which won't be updated until we replay whatwe have already.Reported by Andres Freund while analyzing the failure of a TAP test onbuild farm animal skink (investigation ongoing but probably due tootherwise unrelated timing bugs triggered by this slowness magnified byvalgrind).Discussion:https://postgr.es/m/20220409005910.alw46xqmmgny2sgr%40alap3.anarazel.de1 parent4a736a1 commitacf1dd4
1 file changed
+8
-3
lines changedLines changed: 8 additions & 3 deletions
Original file line number | Diff line number | Diff line change | |
---|---|---|---|
| |||
487 | 487 |
| |
488 | 488 |
| |
489 | 489 |
| |
490 |
| - | |
491 |
| - | |
| 490 | + | |
| 491 | + | |
492 | 492 |
| |
493 | 493 |
| |
494 | 494 |
| |
495 | 495 |
| |
496 | 496 |
| |
497 | 497 |
| |
498 | 498 |
| |
499 |
| - | |
| 499 | + | |
| 500 | + | |
500 | 501 |
| |
| 502 | + | |
| 503 | + | |
| 504 | + | |
| 505 | + | |
501 | 506 |
| |
502 | 507 |
| |
503 | 508 |
| |
|
0 commit comments
Comments
(0)