couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: [jira] [Commented] (COUCHDB-1367) When settings revs_limit on db - the db increases its update_seq counter when viewing stats - but not when getting changes
Date Tue, 27 Dec 2011 03:30:50 GMT
On Tue, Dec 27, 2011 at 9:02 AM, Randall Leeds <> wrote:
> Awesome. I'm glad you testing descending. Sounds like "last_seq" is a
> poor name, because it applies to the particular changes request.
> So then we have this other thing floating around "the sequence number
> of the last replicable document change".
> Interestingly, updates to _local/<id> documents don't affect update_seq.
> Looking into the code, I see all the places where it's bumped
> artificially. It's quite obvious, actually. Search for "update_seq+1"
> in couch_db_updater.erl.
> 1) On setting _revs_limit
> 2) On setting _security
> 3) On some call to increment it (who knows why) that has an HTTP POST
> handler in couch_httpd_misc_handlers that is not exposed by
> etc/couchdb/default.ini.
> I don't see any reason why (1) and (2) need to be bumping this number.
> (3) has been there for a long time but doesn't seem to be part of the
> default public API.
> It appears to have been introduced by Damien in May of 2008 (333d18cf)
> with the commit message:
>  Experimental functionality to increment database update seq, might
> go away, use at own risk.
> I propose we just get rid of all these and then update_seq becomes
> what everyone expects it to be.

It sounds like update_seq an infallible indicator of when a backup is
necessary--better than the filesystem timestamp for the .couch file.
Just compare its value to the one from your previous backup. You'll be
sure to catch not only document updates, but also per-db configuration
settings like _security and _revs_limit.

I'm not sure if that's 100% correct but if it is, it's useful, or at
least not useless.

Iris Couch

View raw message