Re: Configuring synchronous replication - Mailing list pgsql-hackers

On Thu, Sep 23, 2010 at 11:32 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Wed, 2010-09-22 at 13:00 -0400, Robert Haas wrote:
>
>> I think it should be a separate config file, and I think it should be
>> a config file that can be edited using DDL commands as you propose.
>> But it CAN'T be a system catalog, because, among other problems, that
>> rules out cascading slaves, which are a feature a lot of people
>> probably want to eventually have.
>
> ISTM that we can have a system catalog and still have cascading slaves.
> If we administer the catalog via the master, why can't we administer all
> slaves, however they cascade, via the master too?

Well, I guess we could, but is that really convenient?  My gut feeling
is no, but of course it's subjective.

> What other problems are there that mean we *must* have a file? I can't
> see any. Elsewhere, we've established that we can have unregistered
> standbys, so max_wal_senders cannot go away.
>
> If we do have a file, it will be a problem after failover since the file
> will be either absent or potentially out of date.

I'm not sure about that.  I wonder if we can actually turn this into a
feature, with careful design.  Suppose that you have the common
configuration of two machines, A and B.  At any give time, one is the
master and one is the slave.  And let's say you've opted for sync rep,
apply mode, don't wait for disconnected standbys.  Well, you can have
a config file on A that defines B as the slave, and a config file on B
that defines A as the slave.  When failover happens, you still have to
worry about taking a new base backup, removing recovery.conf from the
new master and adding it to the slave, and all that stuff, but the
standby config just works.

Now, admittedly, in more complex topologies, and especially if you're
using configuration options that pertain to the behavior of
disconnected standbys (e.g. wait for them, or retain WAL for them),
you're going to need to adjust the configs.  But I think that's likely
to be true anyway, even with a catalog.  If A is doing sync rep and
waiting for B even when B is disconnected, and the machines switch
roles, it's hard to see how any configuration isn't going to need some
adjustment.  One thing that's nice about the flat file system is that
you can make the configuration changes on the new master before you
promote it (perhaps you had A replicating synchronously to B and B
replicating asynchronously to C, but now that A is dead and B is
promoted, you want the latter replication to become synchronous).
Being able to make those kinds of changes before you start processing
live transactions is possibly useful to some people.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company