Hi, I'm somewhat sorry to have to play this game, as I sure don't feel smarter by composing this email. Quite the contrary.
Robert Haas <robertmh...@gmail.com> writes: > So the "wait forever" case is, in my opinion, > sufficient to demonstrate that we need it, but it's not even my > primary reason for wanting to have it. You're talking about standby registration on the master. You can solve this case without it, because when a slave is not connected it's not giving any feedback (vote, weight, ack) to the master. All you have to do is have the quorum setup in a way that disconnecting your slave means you can't reach the quorum any more. Have it SIGHUP and you can even choose to fix the setup, rather than fix the standby. So no need for registration here, it's just another way to solve the problem. Not saying it's better or worse, just another. Now we could have a summary function on the master showing all the known slaves, their last time of activity, their known current setup, etc, all from the master, but read-only. Would that be useful enough? > The most important reason why I think we should have standby > registration is for simplicity of configuration. Yes, it adds another > configuration file, but that configuration file contains ALL of the > information about which standbys are synchronous. Without standby > registration, this information will inevitably be split between the > master config and the various slave configs and you'll have to look at > all the configurations to be certain you understand how it's going to > end up working. So, here, we have two quite different things to be concerned about. First is the configuration, and I say that managing a distributed setup will be easier for the DBA. Then there's how to obtain a nice view about the distributed system, which again we can achieve from the master without manually registering the standbys. After all, the information you want needs to be there. > As a particular manifestation of this, and as > previously argued and +1'd upthread, the ability to change the set of > standbys to which the master is replicating synchronously without > changing the configuration on the master or any of the existing slaves > seems seems dangerous. Well, you still need to open the HBA for the new standby to be able to connect, and to somehow take a base backup, right? We're not exactly transparent there, yet, are we? > Another reason why I think we should have standby registration is to > allow eventually allow the "streaming WAL backwards" configuration > which has previously been discussed. IOW, you could stream the WAL to > the slave in advance of fsync-ing it on the master. After a power > failure, the machines in the cluster can talk to each other and figure > out which one has the furthest-advanced WAL pointer and stream from > that machine to all the others. This is an appealing configuration > for people using sync rep because it would allow the fsyncs to be done > in parallel rather than sequentially as is currently necessary - but > if you're using it, you're certainly not going to want the master to > enter normal running without waiting to hear from the slave. I love the idea. Now it seems to me that all you need here is the master sending one more information with each WAL "segment", the currently fsync'ed position, which pre-9.1 is implied as being the current LSN from the stream, right? Here I'm not sure to follow you in details, but it seems to me registering the standbys is just another way of achieving the same. To be honest, I don't understand a bit how it helps implement your idea. Regards, -- Dimitri Fontaine PostgreSQL DBA, Architecte -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
