Re: ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeremy Drake <pgsql-patches(at)jdrake(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-patches(at)postgresql(dot)org, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
Date: 2006-07-03 03:43:47
Message-ID: 22669.1151898227@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Jeremy Drake <pgsql-patches(at)jdrake(dot)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 managed to 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?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-07-03 03:58:49 Re: odd 7.4 build failure on new sparc machine
Previous Message Tom Lane 2006-07-03 03:29:19 Re: [HACKERS] PQescapeIdentifier

Browse pgsql-patches by date

  From Date Subject
Next Message Andrew Dunstan 2006-07-03 09:59:01 Re: ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
Previous Message Tom Lane 2006-07-03 03:29:19 Re: [HACKERS] PQescapeIdentifier