forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commitc945af8
committed
Refactor checking whether we've reached the recovery target.
Makes the replay loop slightly more readable, by separating the concerns ofwhether to stop and whether to delay, and how to extract the timestamp froma record.This has the user-visible change that the timestamp of the last appliedrecord is now updated after actually applying it. Before, it was updatedjust before applying it. That meant that pg_last_xact_replay_timestamp()could return the timestamp of a commit record that is in process of beingreplayed, but not yet applied. Normally the difference is small, but ifmin_recovery_apply_delay is set, there could be a significant delay betweenreading a record and applying it.Another behavioral change is that if you recover to a restore point, we stopafter the restore point record, not before it. It makes no difference as faras running queries on the server is concerned, as applying a restore pointrecord changes nothing, but if examine the timeline history you will seethat the new timeline branched off just after the restore point record, notbefore it. One practical consequence is that if you do PITR to the newtimeline, and set recovery target to the same named restore point again, itwill find and stop recovery at the same restore point. Conceptually, I thinkit makes more sense to consider the restore point as part of the newtimeline's history than not.In principle, setting the last-replayed timestamp before actually applyingthe record was a bug all along, but it doesn't seem worth the risk tobackpatch, since min_recovery_apply_delay was only added in 9.4.1 parent10a3b16 commitc945af8
1 file changed
+200
-157
lines changed0 commit comments
Comments
(0)