Re: [pgsql-advocacy] Assembling "top features" list for betaannouncement - Mailing list pgsql-advocacy

From Michael Banck
Subject Re: [pgsql-advocacy] Assembling "top features" list for betaannouncement
Date
Msg-id 1491728411.25270.51.camel@credativ.de
Whole thread Raw
In response to Re: [pgsql-advocacy] Assembling "top features" list for betaannouncement  (Josh Berkus <josh@berkus.org>)
Responses Re: [pgsql-advocacy] Assembling "top features" list for betaannouncement  (Michael Banck <michael.banck@credativ.de>)
List pgsql-advocacy
Am Samstag, den 08.04.2017, 13:26 -0700 schrieb Josh Berkus:
> On 04/08/2017 12:53 PM, Justin Clift wrote:
> > On 8 Apr 2017, at 20:48, Josh Berkus <josh@berkus.org> wrote:
> > <snip>
> >> From a PR standpoint, 5 is the absolute max, and 3 is better.  Really,
> >> the ideal situation is a set of features which can be closely tied
> >> together around a simple theme.
> >
> >  * Replication
> >  * Performance
> >  * Reliability
>
> Well, if we take logical replication, quorum commit, connection failover
> and partitioning, that together is a serious scale-out story.

I'm cautious about how to tie logical replication, partitioning and
connection failover into the (same) scale-out story.

Also, 9.6 had remote_apply, which is arguably at least as important as
quorum commit, as it means querying the standby right afterwards will
result in the expected behavior; if we just had quorum_commit with
synchronous_commit merely to 'on', querying the sync standbys
immediately after a commit might still return the old rows (the new rows
are written to WAL so are crash-safe, but are not necessarily replayed
yet), to the best of my knowledge. So quorum commit extends remote_apply
to multiple standbys.

Finally, note that even though libpq now can handle mutiple hosts in the
connection string, it won't load-balance between those (in contrast to
pgJDBC BTW, which can do load balancing), but just use the next one if
the current connection goes away (i.e. failover). Load-Balancing still
needs external tooling for now.

So we need to be rather careful about not over-selling things here, IMO
(while not under-selling either, of course). Others more familiar with
the new feature will hopefully weigh in.


Michael

--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax:  +49 2166 9901-100
Email: michael.banck@credativ.de

credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer



pgsql-advocacy by date:

Previous
From: Michael Banck
Date:
Subject: Re: [pgsql-advocacy] Assembling "top features" list for betaannouncement
Next
From: Michael Banck
Date:
Subject: Re: [pgsql-advocacy] Assembling "top features" list for betaannouncement