Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: > There's two separate concepts here: > > 1. Automatic registration. When a standby connects, its information gets > permanently added to standby.conf file > > 2. Unregistered standbys. A standby connects, and its information is not in > standby.conf. It's let in anyway, and standby.conf is unchanged. > > We'll need to support unregistered standbys, at least in asynchronous > mode. It's also possible for synchronous standbys, but you can't have the > "if the standby is disconnected, don't finish any commits until it > reconnects and catches up" behavior without registration.
I don't see why we need to support unregistered standbys if we have automatic registration. I'm thinking about that on and off and took time to answer, but I fail to see the reason why you're saying that. What I think we need is an easy way to manually unregister the standby on the master, that would be part of the maintenance routine to disconnect a standby. It seems like an admin function would do, and it so happens that it's how it works with PGQ / londiste. > I'm inclined to not do automatic registration, not for now at > least. Registering a synchronous standby should not be taken lightly. If the > standby gets accidentally added to standby.conf, the master will have to > keep more WAL around and might delay all commits, depending on the options > used. For this reason I think we need to have an easy to use facility to check the system health that includes showing how many WALs are currently kept and which standby is registered to still need them. If you happen you have forgotten to unregister your standby, time to call that admin function from above. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
