Heikki Linnakangas <heikki.linnakangas@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