Robert Haas <robertmh...@gmail.com> writes: > Tell that to the DBA. I bet s/he knows what "all standbys" means. > The fact that the system doesn't know something doesn't make it > unimportant.
Well as a DBA I think I'd much prefer to attribute "votes" to each standby so that each ack is weighted. Let me explain in more details the setup I'm thinking about. The transaction on the master wants a certain "service level" (async, recv, fsync, replay) and a certain number of votes. As proposed earlier, the standby would feedback the last XID known locally in each state (received, synced, replayed) and its current weight, and the master would arbitrate given those information. That's highly flexible, you can have slaves join the party at any point in time, and change 2 user GUC (set by session, transaction, function, database, role, in postgresql.conf) to setup the service level target you want to ensure, from the master. (We could go as far as wanting fsync:2,replay:1 as a service level.) From that you have either the "fail when slave disappear" and the "please don't shut the service down if a slave disappear" settings, per transaction, and per slave too (that depends on its weight, remember). (You can setup the slave weights as powers of 2 and have the service level be masks to allow you to choose precisely which slave will ack your fsync service level, and you can switch this slave at run time easily — sounds cleverer, but sounds also easier to implement given the flexibility it gives — precedents in PostgreSQL? the PITR and WAL Shipping facilities are hard to use, full of traps, but very flexible). You can even give some more weight to one slave while you're maintaining another so that the master just don't complain. I see a need for very dynamic *and decentralized* replication topology setup, I fail to see a need for a centralized registration based setup. > I agree that we don't absolutely need standby registration for some > really basic version of synchronous replication. But I think we'd be > better off biting the bullet and adding it. What does that mechanism allow us to implement we can't do without? -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
