On Sun, Jun 16, 2013 at 11:08 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 16 June 2013 17:25, Samrat Revagade <revagade.sam...@gmail.com> wrote: > > > > > > On Sun, Jun 16, 2013 at 5:10 PM, Simon Riggs <si...@2ndquadrant.com> > wrote: > >> > >> > >> > >> So I strongly object to calling this patch anything to do with > >> "failback safe". You simply don't have enough data to make such a bold > >> claim. (Which is why we call it synchronous replication and not "zero > >> data loss", for example). > >> > >> But that's not the whole story. I can see some utility in a patch that > >> makes all WAL transfer synchronous, rather than just commits. Some > >> name like synchronous_transfer might be appropriate. e.g. > >> synchronous_transfer = all | commit (default). > >> > > > > I agree with you about the fact that, > > Now a days the need of fresh backup in crash recovery seems to be a > major > > problem. > > we might need to change the name of patch if there other problems too > with > > crash recovery. > > (Sorry don't understand) > > Sorry for the confusion. I will change name of a patch. > >> The idea of another slew of parameters that are very similar to > >> synchronous replication but yet somehow different seems weird. I can't > >> see a reason why we'd want a second lot of parameters. Why not just > >> use the existing ones for sync rep? (I'm surprised the Parameter > >> Police haven't visited you in the night...) Sure, we might want to > >> expand the design for how we specify multi-node sync rep, but that is > >> a different patch. > >> > > > > The different set of parameters are needed to differentiate between > > fail-safe standby and synchronous standby, the fail-safe standby and > standby > > in synchronous replication can be two different servers. > > Why would they be different? What possible reason would you have for > that config? There is no *need* for those parameters, the proposal > could work perfectly well without them. > > Let's make this patch fulfill the stated objectives, not add in > optional extras, especially ones that don't appear well thought > through. If you wish to enhance the design for the specification of > multi-node sync rep, make that a separate patch, later. > > I agree with you.I will remove the extra parameters if they are not required in next version of the patch. -- Regards, Samrat Revgade
