Skip site navigation (1) Skip section navigation (2)

Re: Stuck cvs lock on anoncvs repository

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Greg Stark <gsstark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Dave Page <dpage(at)pgadmin(dot)org>, pgsql-www(at)postgresql(dot)org
Subject: Re: Stuck cvs lock on anoncvs repository
Date: 2009-06-28 08:19:25
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-www
Robert Haas wrote:
> On Sat, Jun 27, 2009 at 8:09 PM, Marc G. Fournier<scrappy(at)hub(dot)org> wrote:
>> On Sat, 27 Jun 2009, Alvaro Herrera wrote:
>>> Stefan Kaltenbrunner escribió:
>>>> Greg Stark wrote:
>>>>> do we not have --delete on the rsync command? why doesn't the problem
>>>>> go away on the next sync if we do?
>>>> we do use --delete - but nobody commited after we tagged and before the
>>>> problem got reported so the regular on-commit code didn't kick in and
>>>> forced syncs only happen once a day.
>>> Are we worried about bandwidth wastage that we don't run it more often?
>> More often then when ppl commit?  What would be the point to that?
> Well, the whole point of using rsync is that it only copies what has
> changed, so there is very little overhead involved in running it when
> nothing has changed.  If our current system is adding an additional
> layer of "did anything change?" checking, it's unnecessarily
> duplicating functionality which is already implemented really, really
> well by rsync.

The point is that there is a lot less overhead, not necessarily very
little. And most of the difference is in network overhead - not disk (or

It still has to scan the full repository on both sides and compute the
hashes for all files. Then transfer those across the net. Just to find
out if there is anything to do. Whereas our current solution requires
checking the existence of a single file, and then it will know if there
is anything to do.

Running rsync every 5 minutes *does* have a serious performance impact.
The reason our current system was invented at all is that with rsync, we
simply couldn't sync often enough. We had it at bi-hourly I think, and
that work but created a noticeable load on the anoncvs machine.

> If updating the exclude list is sufficient to fix the problem, maybe
> it's not worth worrying about.  But on the other hand maybe we should
> just rsync it every 15 minutes and forget about it.

Remember that we can't push the timing too far on it, because the cvs
server will send out links to cvsweb right away, and those point to the
anoncvs machine. 15 minutes *might* work, but not much more than that.

Fact is, that *removing* the forced sync would likely fix this issue,
since it will then perform a sync when the tag operation is complete -
not in the middle of it. But I still think it's a good thing to have  a
fallback sync. We could make it run a bit more often (say 4 times a day
instead of 1 or something) which would shorten the time if this happens

 Magnus Hagander

In response to


pgsql-www by date

Next:From: Stefan KaltenbrunnerDate: 2009-06-28 08:23:36
Subject: Re: Stuck cvs lock on anoncvs repository
Previous:From: Alvaro HerreraDate: 2009-06-28 04:08:53
Subject: Re: Stuck cvs lock on anoncvs repository

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group