Thomas Munro <thomas.mu...@gmail.com> writes: > Once we had the checkpointer running, we could also consider making > the end-of-recovery checkpoint optional, or at least the wait for it > to complete. I haven't shown that in this patch, but it's just > different checkpoint request flags and possibly an end-of-recovery > record. What problems do you foresee with that? Why should we have > "fast" promotion but not "fast" crash recovery?
I think that the rationale for that had something to do with trying to reduce the costs of repeated crashes. If you've had one crash, you might well have another one in your near future, due to the same problem recurring. Therefore, avoiding multiple replays of the same WAL is attractive; and to do that we have to complete a checkpoint before giving users a chance to crash us again. I'm not sure what I think about your primary proposal here. On the one hand, optimizing crash recovery ought to be pretty darn far down our priority list; if it happens often enough for performance to be a consideration then we have worse problems to fix. Also, at least in theory, not running the bgwriter/checkpointer makes for fewer moving parts and thus better odds of completing crash recovery successfully. On the other hand, it could be argued that running without the bgwriter/checkpointer actually makes recovery less reliable, since that's a far less thoroughly-tested operating regime than when they're active. tl;dr: I think this should be much less about performance than about whether we successfully recover or not. Maybe there's still a case for changing in that framework, though. regards, tom lane