Re: Patch for fail-back without fresh backup

On Sun, Jun 16, 2013 at 11:08 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:

> On 16 June 2013 17:25, Samrat Revagade <revagade(dot)samrat(at)gmail(dot)com> wrote:
> >
> >
> > On Sun, Jun 16, 2013 at 5:10 PM, Simon Riggs <simon(at)2ndquadrant(dot)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