[
https://issues.apache.org/jira/browse/COUCHDB-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds updated COUCHDB-704:
----------------------------------
Attachment: save-all-rep-checkpoints.patch
Here's an updated patch that applies to current trunk.
Differences to the previous patch:
I bumped the number of checkpoints saved back up to 50 because who doesn't love
a little paranoia?
No longer restart on conflict. If this is a self-replication we want to bail.
If it's not, let the user restart it.
Don't keep the stats through a restart. Not sure why I thought that was wise.
The incremental stats are stored in each log entry.
Just trying to keep this fresh. If you see any reason this shouldn't be applied
please let me know.
> Replication can lose checkpoints
> --------------------------------
>
> Key: COUCHDB-704
> URL: https://issues.apache.org/jira/browse/COUCHDB-704
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
> Affects Versions: 0.12
> Reporter: Randall Leeds
> Priority: Minor
> Attachments: save-all-rep-checkpoints.patch
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> When saving replication checkpoints in the _local/<repid> document the new
> entry is always pushed onto the _original_ "history" list property that
> existed at the start of the replication. When any number of things causes the
> checkpoint to be written to only one of the databases the head of the history
> list gets out of sync. Subsequent attempts to start this replication must
> start from the latest common replication log entry in the _original_ history,
> as though this replication never occurred.
> A better idea is to push every checkpoint onto the history instead of
> replacing the head on each save.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
