Pierangelo Masarati wrote:
Pierangelo Masarati wrote:
I've backed out RID, which is now decimal again (0..999), and let sctxcsn be NULL when no maxcsn can be gathered. In this case, after running test050 and leaving the directories in place, if I restart the two servers and perform an add as the first operation, the server acting as a consumer crashes both in refreshOnly and in refreshAndPersist modes (I plan to modify the test in order to trigger this case, so we can track regressions once it's fixed). My question is now:
- is it correct that syncprov_op_response() is set up at all for those
modifications that come from the producer?
Obviously yes, to enable cascaded replication
- If it is, should maxcsn be available?
don't know yet
- If not, how should its absence be dealt with?
it should definitely be dealt with: cascaded replication incurs into this issue; after adding cookie logging, testrun/slapd.4.log after test019 is full of
syncprov_sendresp: cookie=rid=001,csn=
- otherwise, if yes, why isn't it available?
dunno yet.
The syncrepl_entry() function doesn't call slap_queue_csn()/slap_graduate_commit_csn(), therefore the CSN is not propagated. The reason for that is because during a refresh phase, updates are not received in CSN order. We only propagate the CSN when we receive a new cookie from the provider, and the provider will only send it when the refresh phase is completed. This is to prevent the local contextCSN from advancing past its actual content...
Once we transition into persist phase, the provider should be sending a cookie with every update, and we should be propagating it. It looks like perhaps syncrepl_entry() is broken here in that it doesn't know whether or not a cookie was received. I'll look into that.