Re: Patch for fail-back without fresh backup

From: Samrat Revagade <revagade(dot)samrat(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch for fail-back without fresh backup
Date: 2013-06-16 16:25:37
Message-ID: CAF8Q-GwUFuXiVpYZCdGJct2viZ5CAPXoN+J6rFJK2hxN-HoGQQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

> I'm worried to see that adding this feature and yet turning it off
> causes a measureable drop in performance. I don't think we want that
> at all. That clearly needs more work and thought.
>
> I also think your performance results are somewhat bogus. Fast
> transaction workloads were already mostly commit waits - measurements
> of what happens to large loads, index builds etc would likely reveal
> something quite different.
>
>
I will test the other scenarios and post the results.

>
> --
> Simon Riggs http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>

--
Regards,

Samrat Revgade

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-06-16 16:59:55 Re: In progress INSERT wrecks plans on table
Previous Message Cédric Villemain 2013-06-16 16:20:27 Re: [PATCH] Remove useless USE_PGXS support in contrib