Re: Buildfarm "master-next" branch? (was: Dynamic Shared Memory stuff)

On 04/17/2014 12:08 AM, Robert Haas wrote:
> On Tue, Apr 15, 2014 at 10:46 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> On Wed, Apr 16, 2014 at 3:01 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Tue, Apr 15, 2014 at 12:33 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>>> On Mon, Apr 14, 2014 at 10:03 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>>>> For the create case, I'm wondering if we should put the block that
>>>>> tests for !hmap *before* the _dosmaperr() and check for EEXIST.  What
>>>>> is your opinion?
>>>>
>>>> Either way is okay, but I think the way you are suggesting is better as it
>>>> will make code consistent with other place (PGSharedMemoryCreate()).
>>>
>>> OK, can you prepare a patch?
>>
>> Please find attached patch to address this issue.
>> One minor point to note is that now we have to call GetLastError() twice,
>> once inside error path and once to check EEXIST, but I think that is okay
>> as existing code in PGSharedMemoryCreate() does it that way.
> 
> OK.  I committed this blindly, but I don't have a Windows dev
> environment, so please keep an eye on the Windows buildfarm members
> and provide follow-on patches if any of them get unhappy about this.

Given that we're doing this a fair bit, is it reasonable to define a
"master-next" branch in git and have the buildfarm (or at least the
Windows members) build that?

Permit master-next to be rebased and reset.

That way it's possible to fire stuff off and see what happens on the
buildfarm without introducing broken commits unnecessarily.

Thoughts?


-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services