On 5 December 2012 21:15, Tom Lane <t...@sss.pgh.pa.us> wrote: > Simon Riggs <si...@2ndquadrant.com> writes: >> On 5 December 2012 18:48, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> On further thought, it seems like recovery_pause_at_target is rather >>> misdesigned anyway, and taking recovery target parameters from >>> recovery.conf is an obsolete API that was designed in a world before hot >>> standby. What I suggest people really want, if they're trying to >>> interactively determine how far to roll forward, is this: >>> ... > >> Can't remember why we didn't go for the full API last time. I'll have >> another go, in HEAD. > > That's fine, but the immediate question is what are we doing to fix > the back branches. I think everyone is clear that we should be testing > LocalHotStandbyActive rather than precursor conditions to see if a pause > is allowed, but are we going to do anything more than that?
No > The only other thing I really wanted to do is not have the in-loop pause > occur after we've taken actions that are effectively part of the WAL > apply step. I think ideally it should happen just before or after the > recoveryStopsHere stanza. Last night I worried about adding an extra > spinlock acquire to make that work, but today I wonder if we couldn't > get away with just a naked > > if (xlogctl->recoveryPause) > recoveryPausesHere(); > > The argument for this is that although we might fetch a slightly stale > value of the shared variable, it can't be very stale --- certainly no > older than the spinlock acquisition near the bottom of the previous > iteration of the loop. And this is a highly asynchronous feature > anyhow, so fuzziness of plus or minus one WAL record in when the pause > gets honored is not going to be detectable. Hence an extra spinlock > acquisition is not worth the cost. Yep, thats fine. Are you doing this or do you want me to? Don't mind either way. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
