So what status are we on? Are we going to release 9.2.2 as it is? Or withdraw current 9.2.2? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp
> 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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
