From dev-return-19844-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Tue Dec 27 04:52:52 2011 Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3F1037C3B for ; Tue, 27 Dec 2011 04:52:52 +0000 (UTC) Received: (qmail 86411 invoked by uid 500); 27 Dec 2011 04:52:51 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 86385 invoked by uid 500); 27 Dec 2011 04:52:50 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 86370 invoked by uid 99); 27 Dec 2011 04:52:49 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Dec 2011 04:52:49 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of randall.leeds@gmail.com designates 209.85.210.180 as permitted sender) Received: from [209.85.210.180] (HELO mail-iy0-f180.google.com) (209.85.210.180) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Dec 2011 04:52:44 +0000 Received: by iazz13 with SMTP id z13so22238976iaz.11 for ; Mon, 26 Dec 2011 20:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=1f9G0gDpV3x+ugr8MU9uXo77TSQ+03h/WteMQlexc/A=; b=CWHrPwCLiRtN8Io102SaR0NL23wccw8j11K7sQcMN5ZCMjf7MPaVKhg/8MtAG2gOWG CYExM6U0uzmXyRzGgTP7mIZq50+KoAK3s8Ic+3bv+LZ0qfXM82zGkwcJ6l4Rr7suLRdn HSbltNSdw7DQsDvP8b/qd4aPyll3IWaDHRims= MIME-Version: 1.0 Received: by 10.50.194.202 with SMTP id hy10mr29039033igc.23.1324961543786; Mon, 26 Dec 2011 20:52:23 -0800 (PST) Received: by 10.42.213.194 with HTTP; Mon, 26 Dec 2011 20:52:23 -0800 (PST) In-Reply-To: References: <2073127356.24602.1324243590757.JavaMail.tomcat@hel.zones.apache.org> <1765975633.44958.1324877790680.JavaMail.tomcat@hel.zones.apache.org> Date: Mon, 26 Dec 2011 23:52:23 -0500 Message-ID: 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 From: Randall Leeds To: dev@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Dec 26, 2011 at 22:30, Jason Smith wrote: > 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/ 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: >> >> =C2=A0Experimental 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 Thanks a ton for pointing out the operations issue of backup here; I hadn't considered it. It's worth noting, as I did before, that _local docs do not affect update_seq, though that's probably not a disaster for backup scenarios unless _local is being used by something other than the replicator. -R