On Fri, Sep 17, 2010 at 6:41 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: >>> 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. >> >> My patch provides those two requirements without standby registration, >> so we very clearly don't "need" standby registration. > > It's still not clear to me how you would configure things like "wait for ack > from reporting slave, but not other slaves" or "wait until replayed in the > server on the west coast" in your proposal. Maybe it's possible, but doesn't > seem very intuitive, requiring careful configuration in both the master and > the slaves.
Agreed. I think this will be much simpler if all the configuration is in one place (on the master). > In your proposal, you also need to be careful not to connect e.g a test > slave with "synchronous_replication_service = apply" to the master, or it > will possible shadow a real production slave, acknowledging transactions > that are not yet received by the real slave. It's certainly possible to > screw up with standby registration too, but you have more direct control of > the master behavior in the master, instead of distributing it across all > slaves. Similarly agreed. >> The question is do we want standby registration on master and if so, >> why? > > Well, aside from how to configure synchronous replication, standby > registration would help with retaining the right amount of WAL in the > master. wal_keep_segments doesn't guarantee that enough is retained, and > OTOH when all standbys are connected you retain much more than might be > required. +1. > Giving names to slaves also allows you to view their status in the master in > a more intuitive format. Something like: > > postgres=# SELECT * FROM pg_slave_status ; > name | connected | received | fsyncd | applied > ------------+-----------+------------+------------+------------ > reporting | t | 0/26000020 | 0/26000020 | 0/25550020 > ha-standby | t | 0/26000020 | 0/26000020 | 0/26000020 > testserver | f | | 0/15000020 | > (3 rows) +1. Having said all of the above, I am not in favor your (Heikki's) proposal to configure sync/async on the slave and the level on the master. That seems like a somewhat bizarre division of labor, splitting what is essentially one setting across two machines. >>> For the control between async/recv/fsync/replay, I like to think in >>> terms of >>> a) asynchronous vs synchronous >>> b) if it's synchronous, how synchronous is it? recv, fsync or replay? >>> >>> I think it makes most sense to set sync vs. async in the master, and the >>> level of synchronicity in the slave. Although I have sympathy for the >>> argument that it's simpler if you configure it all from the master side >>> as well. >> >> I have catered for such requests by suggesting a plugin that allows you >> to implement that complexity without overburdening the core code. > > Well, plugins are certainly one possibility, but then we need to design the > plugin API. I've been thinking along the lines of a proxy, which can > implement whatever logic you want to decide when to send the acknowledgment. > With a proxy as well, if we push any features people that want to a proxy or > plugin, we need to make sure that the proxy/plugin has all the necessary > information available. I'm not really sold on the proxy idea. That seems like it adds a lot of configuration complexity, not to mention additional hops. Of course, the plug-in idea also won't be suitable for any but the most advanced users. I think of the two I prefer the idea of a plug-in, slightly, but maybe this doesn't have to be done in version 1. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
