Re: Additional options for Sync Replication

Yeb Havinga <yebhavinga(at)gmail(dot)com> writes:
> The dba interface for recv|fsync|apply seems to be pretty stable, so
> supporting that for years should be without risk. How it works under the
> hood - the beta period seems like *the* opportunity to attrach mayor testing
> from all people waiting to get their hands on syncrep.

+1

> It would be better to just support it (recv|fsync|apply),
> or no syncrep at all. Syncrep is incomplete without it.

Agreed.

More than that, I think we should evaluate this patch on a cost/benefit
ratio, rather than trying to apply to it all those procedural fences
that we don't have, and that we don't have the size to benefit from.

This whole thread only managed to raise the cost of the feature, but
compared to its benefits, it's still a wash. Is there any good reason
that I missed to ask all our users to wait for at best another year to
get the SyncRep waiting behavior that makes sense and has been agreed on
for a very long time already?

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

PS : we already tweaked the UI in such a way that controling this
feature from the standby makes no sense. What we talked about was
to setup on the master which durability level you need, and on each
standby which one you're able to provide. Then you mix&match.
That won't fly with current way to setup the sync standby list.

So current recv|fsync|apply patch is IMO finishing the 9.1 work.