On Thu, Sep 1, 2016 at 11:36 AM, Josh Berkus <josh@agliodbs.com> wrote:
> So, I have to say, this doesn't *feel* like a major press-worthy feature
> yet. It will be in 10, but is it right now?
IMHO, what makes this a big deal is that we also got
synchronous_commit=remote_apply. That means that, in PostgreSQL 9.6,
for the first time, you can build a reliable read-scaling cluster,
where "reliable" means that a value that you wrote on the master is
guaranteed to be visible in a subsequent read from a standby. I think
the release notes and the release announcement should both mention
those two things in conjunction with each other, because the
combination is very powerful.
If you have only synchronous_commit=remote_apply, you can have a
single read replica and you can be sure that if you commit a change on
the master and then read it back from the replica, you'll see the
result of the change. No previous release could guarantee this, and
it's nice, but having only one replica that can do this wouldn't be
very exciting.
If you have only multiple synchronous standbys, you can have a whole
bunch of standbys and wait for WAL to be written or flushed on any
number of them, which I guess is good if your transactions are made of
solid platinum, but most people will find limited application for
this.
But if you have BOTH features, then you can set
synchronous_standby_names to require an ACK from *every* standby, and
you can set synchronous_commit=remote_apply so that you wait for WAL
to be applied, not just fsync'd, and now you are guaranteed that
whenever you make a change on the master and then read it back from
any one of your read-replicas, it will be there! And that, IMHO, is
pretty cool.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company