Re: ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
От | Andrew Dunstan |
---|---|
Тема | Re: ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) |
Дата | |
Msg-id | 4053.24.211.165.134.1151920741.squirrel@www.dunslane.net обсуждение исходный текст |
Ответ на | Re: ADD/DROPS INHERIT (actually INHERIT / NO INHERIT) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
|
Список | 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 по дате отправления: