Thank you. > I think moving CheckRecoveryConsistency() after redo apply loop might cause > a problem. > As currently it is done before recoveryStopsHere() function, which can allow > connections > on HOTSTANDY. But now if due to some reason recovery pauses or stops due to > above function, > connections might not be allowed as CheckRecoveryConsistency() is not > called.
It depends on the precise meaning of minRecoveryPoint. I've not found the explicit explanation for it. Currently minRecoveryPoint is updated only in XLogFlush. Other updates of it seems to reset to InvalidXLogRecPtr. XLogFlush seems to be called AFTER the redo core operation has been done, at least in xact_redo_commit_internal. I shows me that the meaning of minRecoveryPoint is that "Just AFTER applying the XLog at current LSN, the database files will be assumed to be consistent." At Mon, 10 Dec 2012 00:36:31 +0900, Fujii Masao <masao.fu...@gmail.com> wrote in <cahgqgwg4w5qz7+ljimg8xxuevwz0bynihmzlzmwf0j6kbiu...@mail.gmail.com> > Yes, so we should just add the CheckRecoveryConsistency() call after > rm_redo rather than moving it? This issue is related to the old discussion: > http://archives.postgresql.org/pgsql-bugs/2012-09/msg00101.php Since I've not cleary understood the problem of missing it before redo, and it also seems to have no harm on performance, I have no objection to place it both before and after of redo. -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
