Re: ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) - Mailing list pgsql-patches

From Andrew Dunstan
Subject Re: ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
Date
Msg-id 4053.24.211.165.134.1151920741.squirrel@www.dunslane.net
Whole thread Raw
In response to Re: ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
List pgsql-patches
Tom Lane said:
> Jeremy Drake <pgsql-patches@jdrake.com> writes:
>> On Sun, 2 Jul 2006, Tom Lane wrote:
>>> Nah, it was a false alarm: I was looking at the first post-patch
>>> report,
>>>
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mongoose&dt=2006-07-02%2003:30:01>>> but apparently mongoose had
managedto pick up a partially-updated 
>>> snapshot.  The later reports (including mongoose's own next try an
>>> hour later) were all OK.
>
>> As the keeper of mongoose, is there anything I should do to prevent it
>> from picking up a partially-updated snapshot?  Or is this just a race
>> condition that's bound to happen now and then?
>
> Well, it's certainly not *your* problem to fix.  I suspect that this
> risk is inherent in CVS --- although there might also be something
> involved about our primary-vs-mirror CVS setup.  Does anyone know
> exactly how the mirroring is done and whether it makes any attempt to
> ensure a consistent copy?
>

Since CVS updates are not atomic, it's hard to see how mirroring could be,
unless you did something like disallow updates, mirror, allow updates. I
suspect such a cure would be worse than the disease. This is such a rare
event that I don't think it's worth the trouble. Buildfarm members are doing
200 builds a day or more, and I can't recall having seen this before.

cheers

andrew



pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
Next
From: Tom Lane
Date:
Subject: Re: ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)