On Thursday, September 13, 2012 5:52 PM Heikki Linnakangas wrote:
On 12.09.2012 22:03, Fujii Masao wrote:
> On Wed, Sep 12, 2012 at 8:47 PM,<amit.kapila@huawei.com> wrote:
>> The following bug has been logged on the website:
>>
>>> Bug reference: 7533
>>> Logged by: Amit Kapila
>>> Email address: amit.kapila@huawei.com
>>> PostgreSQL version: 9.2.0
>>> Operating system: Suse
>>> Description:
>>
>>> M host is primary, S host is standby and CS host is cascaded =
standby.
>>
>Hmm, I think the CheckRecoveryConsistency() call in the redo loop is =
misplaced. It's called after we got a record from=20
> ReadRecord, but *before* replaying it (rm_redo). Even if replaying =
record X makes the system consistent, we won't check=20
> and notice that until we have fetched record X+1. In this particular =
test case, record X is a shutdown checkpoint=20
> record, but it could as well be a running-xacts record, or the record =
that reaches minRecoveryPoint.
> Does the problem go away if you just move the =
CheckRecoveryConsistency() call *after* rm_redo (attached)?
This will resolve the problem I have reported but moving down might =
create another problem as due to function
recoveryPauseHere(), the recovery might get paused and in current code a =
client might be able to connect even in that state as =
CheckRecoveryConsistency() is done before that. However after suggested =
change it might happen that Client will not be able to connect.
If you see any problem in what I explain then can we think of calling =
CheckRecoveryConsistency() both at current place and the place you have =
proposes. If my description doesn't make any sense (as that is only my =
suspicion) then we can move the function down and fix the defect.
Thank you for giving so quick response about the defect.
With Regards,
Amit Kapila.