Andres Freund <and...@2ndquadrant.com> writes: > On 2012-12-04 21:27:34 -0500, Tom Lane wrote: >> So the upshot is that I propose a patch more like the attached.
> Without having run anything so far it looks good to me. BTW, while on the theme of the pause feature being several bricks shy of a load, it looks to me like the place that it was added to the replay loop was less than sane as well. Presumably the purpose of a pause is to let you stop application of the WAL at exactly the current spot; but you can *not* do that midway through application of the record, and where it is is effectively that. As soon as we've updated xlogctl->replayEndRecPtr, we're committed to replay the record, because we can't guarantee that the controlfile minRecoveryPoint doesn't get pushed up to that point by buffer flush activity. So an abort here could leave the database in an unrestartable condition. I guess the idea of putting it there was to save one spinlock acquire, but I'm having a bit of a hard time believing that one spinlock acquire per WAL record means much. Still we could possibly preserve that attribute by moving the pause down to just after the update of xlogctl->recoveryLastRecPtr. Thoughts? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs