On Wed, May 5, 2010 at 05:31, Julian Foad <julian.foad_at_wandisco.com> wrote:
>...
> All the above: r941212.
Cool.
>...
>> > +/* Remove the pristine text with SHA-1 checksum SHA1_CHECKSUM from the
>> > + * pristine store, iff it is not referenced by any of the (other) WC DB
>> > + * tables. */
>>
>> Also remember that we don't want to remove pristines why
>> administrative locks (WCLOCK) are present. That may signify a commit
>> is occurring and needed pristines are transiently living in the
>> pristine storage.
>
> I need to think on this some more and learn about WCLOCK.
>
> If I'm using "pristine_remove" in a general garbage-collection manner
> (outside of any code path that installs pristine texts), I would want to
> bail if there are any entries in the WCLOCK table.
Yes.
I think. :-P ... if those locks are held by "this process", then
sure... something may be holding the SHA-1 keys and will be doing
something with those pristines. If the locks are *not* held by this
process, then something else is doing some work (definitely skip
GC'ing!) or a prior run failed in some way and there are stale locks
remaining, pending an 'svn cleanup'. Presumably, there will also be
some work in the queue.
> If I'm using "pristine_remove" within a commit or update code path
> (where I am also installing new text bases, but I can ensure that the
> one I'm trying to remove is not one that I'm in the process of
> installing), then I would want to bail if there are any locks in the
> WCLOCK table *other than* those locks that are in WC_CTX.
If the pristine is not in the table, and there are no Other Locks,
then yes. I think this sounds right. I believe the design should be
"pristines that need to live beyond locks require a reference from a
table". Thus, if your process does not have a private reference to a
pristine (known via code path), and no *other* process has one (by
virtue of no WCLOCK), then you're free to GC pristines.
Cheers,
-g
Received on 2010-05-05 12:55:46 CEST