Simon Riggs wrote:
> Good catch.
>
> I've updated Julien's patch to reflect Michael's suggestion.
>
> Looks good to apply immediately.
>
> 14e8803f1 was only a partial patch for the syncrep code, so I don't
> see any reason to keep the code as it currently is in 9.5/9.6.
>
> Any objections to
On 10/08/2016 09:43, Michael Paquier wrote:
> On Wed, Aug 10, 2016 at 4:29 PM, Simon Riggs wrote:
>>
>> I've updated Julien's patch to reflect Michael's suggestion.
Thanks to you and Michael.
>> 14e8803f1 was only a partial patch for the syncrep code, so I don't
>> see any reason to keep the cod
On Wed, Aug 10, 2016 at 4:29 PM, Simon Riggs wrote:
> 14e8803f1 was only a partial patch for the syncrep code, so I don't
> see any reason to keep the code as it currently is in 9.5/9.6.
>
> Any objections to backpatching this to 9.5 and 9.6?
None from here.
--
Michael
--
Sent via pgsql-hacke
On 10 August 2016 at 06:24, Michael Paquier wrote:
> On Tue, Aug 9, 2016 at 5:34 PM, Julien Rouhaud
> wrote:
>> Since 14e8803f1, it's not necessary to acquire the SyncRepLock to see up
>> to date data. But it looks like this commit didn't update all the
>> comment around MyProc->syncRepState, wh
On Tue, Aug 9, 2016 at 5:34 PM, Julien Rouhaud
wrote:
> Since 14e8803f1, it's not necessary to acquire the SyncRepLock to see up
> to date data. But it looks like this commit didn't update all the
> comment around MyProc->syncRepState, which still mention retrieving the
> value without and without
Hello,
Since 14e8803f1, it's not necessary to acquire the SyncRepLock to see up
to date data. But it looks like this commit didn't update all the
comment around MyProc->syncRepState, which still mention retrieving the
value without and without lock. Also, there's I think a now unneeded
test to tr
