On Fri, Dec 12, 2014 at 9:38 PM, Heikki Linnakangas
wrote:
> On 12/12/2014 04:29 AM, Michael Paquier wrote:
>>
>> On Thu, Dec 11, 2014 at 10:07 PM, Heikki Linnakangas <
>> hlinnakan...@vmware.com> wrote:
>>
>>> I propose the attached (I admit I haven't tested it).
>>>
>> Actually if you do it this
On 12/12/2014 04:29 AM, Michael Paquier wrote:
On Thu, Dec 11, 2014 at 10:07 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
I propose the attached (I admit I haven't tested it).
Actually if you do it this way I think that it would be worth adding the
small optimization Fujii-san men
On Thu, Dec 11, 2014 at 10:07 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> * I don't like filling the priorities-array in
> SyncRepGetSynchronousStandby(). It might be convenient for the one caller
> that needs it, but it seems pretty ad hoc.
>
> In fact, I don't really see the point
On 11/18/2014 11:23 PM, Michael Paquier wrote:
On Tue, Nov 18, 2014 at 6:33 PM, Simon Riggs wrote:
Can we just wait on this patch until we have the whole feature?
Well, this may take some time to even define, and even if goals are clearly
defined this may take even more time to have a protot
On Tue, Nov 18, 2014 at 6:33 PM, Simon Riggs wrote:
> Can we just wait on this patch until we have the whole feature?
>
Well, this may take some time to even define, and even if goals are clearly
defined this may take even more time to have a prototype to discuss about.
> We quite often break l
On 18 November 2014 00:02, Michael Paquier wrote:
>> I've not read the patches yet. But while I was reading the code around
>> sync node detection, I thought that it might be good idea to treat the
>> node with priority as special. That is, if we find the active node with
>> the priority 1, we ca
On Tue, Nov 18, 2014 at 3:03 AM, Fujii Masao wrote:
> On Mon, Nov 17, 2014 at 2:20 PM, Michael Paquier
> wrote:
>> On Sun, Nov 16, 2014 at 9:07 PM, Michael Paquier
>> wrote:
>>> I'll send an updated patch tomorrow.
>>
>> Here are updated versions. I divided the patch into two for clarity,
>> the
On Mon, Nov 17, 2014 at 2:20 PM, Michael Paquier
wrote:
> On Sun, Nov 16, 2014 at 9:07 PM, Michael Paquier
> wrote:
>> I'll send an updated patch tomorrow.
>
> Here are updated versions. I divided the patch into two for clarity,
> the first one is the actual refactoring patch, renaming
> SyncRepG
On Mon, Nov 17, 2014 at 10:00 PM, Simon Riggs wrote:
> On 16 November 2014 12:07, Michael Paquier wrote:
>
>> Let's work
>> the multiple node thing once we have a better spec of how to do it,
>> visibly using a dedicated micro-language within s_s_names.
>
> Hmm, please make sure that is a new pos
On 16 November 2014 12:07, Michael Paquier wrote:
> Let's work
> the multiple node thing once we have a better spec of how to do it,
> visibly using a dedicated micro-language within s_s_names.
Hmm, please make sure that is a new post. That is easily something I
could disagree with, even though
On Sun, Nov 16, 2014 at 9:07 PM, Michael Paquier
wrote:
> I'll send an updated patch tomorrow.
Here are updated versions. I divided the patch into two for clarity,
the first one is the actual refactoring patch, renaming
SyncRepGetSynchronousNode to SyncRepGetSynchronousStandby (+alpha,
like updat
Thanks for the comments!
On Sun, Nov 16, 2014 at 8:32 PM, Simon Riggs wrote:
> On 31 October 2014 00:27, Michael Paquier wrote:
>> On Fri, Oct 31, 2014 at 6:59 AM, Jim Nasby wrote:
>>>
>>> If we stick with this version I'd argue it makes more sense to just stick
>>> the sync_node = and priority
On 31 October 2014 00:27, Michael Paquier wrote:
> On Fri, Oct 31, 2014 at 6:59 AM, Jim Nasby wrote:
>>
>> If we stick with this version I'd argue it makes more sense to just stick
>> the sync_node = and priority = statements into the if block and ditch the
>> continue.
>
> Let's go with the cle
On Fri, Oct 31, 2014 at 6:59 AM, Jim Nasby wrote:
> If we stick with this version I'd argue it makes more sense to just stick
> the sync_node = and priority = statements into the if block and ditch the
> continue.
>
Let's go with the cleaner version then, I'd prefer code that can be read
easily
On 10/30/14, 8:05 AM, Michael Paquier wrote:
This switches from using a single if() with multiple conditions &&'d
together to a bunch of if() continue's. I don't know if those will perform
the same, and AFAIK this is pretty performance critical.
Well, we could still use the old notation with a s
Thanks for your review! (No worries for creating a new thread, I don't
mind as this is not a huge patch. I think you could have downloaded
the mbox from postgresql.org btw).
On Thu, Oct 30, 2014 at 8:24 AM, Jim Nasby wrote:
> SyncRepGetSynchronousNode():
> IMHO, the top comment should mention tha
Original message (sorry, don't have a copy to reply to :( ):
http://www.postgresql.org/message-id/CAB7nPqThX=WvuGA1J-_CQ293dK3FmUivuYkNvHR0W5xjEc=o...@mail.gmail.com
Commitfest URL: https://commitfest.postgresql.org/action/patch_view?id=1579
Summary:
I'd like someone to chime in on the potential
17 matches
Mail list logo
