All,
I'm answering this strictly from the perspective of my company's
customers and what they've asked for. It does not reflect on what
features are reflected in whatever patch.
> * Support multiple standbys with various synchronization levels.
Essential. We already have two customers who want to have one synch and
several async standbys.
> * What happens if a synchronous standby isn't connected at the moment?
> Return immediately vs. wait forever.
Essential.
Actually, we need a replication_return_timeout. That is, wait X seconds
on the standby and then give up. Again, in the systems I'm working
with, we'd want to wait 5 seconds and then abort replication.
> * Per-transaction control. Some transactions are important, others are not.
Low priority.
I see this as a 9.2 feature. Nobody I know is asking for it yet, and I
think we need to get the other stuff right first.
> * Quorum commit. Wait until n standbys acknowledge. n=1 and n=all
> servers can be seen as important special cases of this.
Medium priority. This would go together with having a registry of
standbies. The only reason I don't call this low priority is that it
would catapult PostgreSQL into the realm of CAP databases, assuming that
we could deal with the re-mastering issue as well.
> * async, recv, fsync and replay levels of synchronization.
Fsync vs. Replay is low priority (as in, we could live with just one or
the other), but the others are all high priority. Again, this should be
settable *per standby*.
> So what should the user interface be like? Given the 1st and 2nd
> requirement, we need standby registration. If some standbys are
> important and others are not, the master needs to distinguish between
> them to be able to determine that a transaction is safely delivered to
> the important standbys.
There are considerable benefits to having a standby registry with a
table-like interface. Particularly, one where we could change
replication via UPDATE (or ALTER STANDBY) statements.
a) we could eliminate a bunch of GUCs and control standby behavior
instead via the table interface.
b) DBAs and monitoring tools could see at a glance what the status of
their replication network was.
c) we could easily add new features (like quorum groups) without
breaking prior setups.
d) it would become easy rather than a PITA to construct GUI replication
management tools.
e) as previously mentioned, we could use it to have far more intelligent
control over what WAL segments to keep, both on the master and in some
distributed archive.
Note, however, that the data from this pseudo-table would need to be
replicated to the standby servers somehow in order to support re-mastering.
Take all the above with a grain of salt, though. The important thing is
to get *some kind* of synch rep into 9.1, and get 9.1 out on time.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
