On Mon, Oct 27, 2014 at 8:54 PM, Tom Lane wrote:
> That argument is nonsense. I complained about a lack of close analysis,
> but with close analysis I think this is perfectly safe; or at least no
> less safe than what's there now, with its not terribly bulletproof
> assumption that a suitable mem
Robert Haas writes:
> On Mon, Oct 27, 2014 at 4:27 PM, Tom Lane wrote:
>> Neither of those messages seem to me to bear on this point. AFAICS,
>> the unlocked hasMessages test has a race condition, which the comment
>> just above it argues isn't a problem in practice. What I propose above
>> wou
On Mon, Oct 27, 2014 at 4:27 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Oct 27, 2014 at 3:31 PM, Tom Lane wrote:
>>> Why could we not remove the hasMessages flags again, and change the
>>> unlocked test
>>>
>>> if (!stateP->hasMessages)
>>> return 0;
>>>
>>> into
>>>
>>> if (stateP->ne
Robert Haas writes:
> On Mon, Oct 27, 2014 at 3:31 PM, Tom Lane wrote:
>> Why could we not remove the hasMessages flags again, and change the
>> unlocked test
>>
>> if (!stateP->hasMessages)
>> return 0;
>>
>> into
>>
>> if (stateP->nextMsgNum == segP->maxMsgNum &&
>> !stateP->resetState)
>> r
On Mon, Oct 27, 2014 at 3:31 PM, Tom Lane wrote:
> I happened to be looking at sinvaladt.c and noticed the loop added in
> commit b4fbe392f8ff6ff1a66b488eb7197eef9e1770a4:
>
> /*
> * Now that the maxMsgNum change is globally visible, we give everyone
> * a swift kick to m
I happened to be looking at sinvaladt.c and noticed the loop added in
commit b4fbe392f8ff6ff1a66b488eb7197eef9e1770a4:
/*
* Now that the maxMsgNum change is globally visible, we give everyone
* a swift kick to make sure they read the newly added messages.
* Relea
