3) As plainly documented, in syncrepl all of the configuration and important
state is consumer-side; the provider doesn't keep track of anything about any
consumers. This is why syncrepl is flexible enough to allow consumers to be
added arbitrarily without needing to reconfig/restart or otherwise disturb the
provider. It's also the only way to have really scalable replication. Since
the provider has no knowledge of individual consumers, *of course* the
provider doesn't complain when a consumer goes down. This fact is self-evident
if you actually read the docs.
In fact, if you stated this this thing, you have *clearly no idea* how replication (as a term) should work.
So, again, I don't care if you write the code, and if you want to help or not. If you don't want to help, just don't write.
*Clearly* the provider SHOULD provide information, if it has pushed all the updates to the slaves.
Ok, your excuse is that this is due to the fact, that the provider does not keep track of slaves. Ergo?
The slaves are wrongly implemented. And *they* should provide the information if they have the connection and are up2date or not.
This is of course totally implementation-dependent (in this case, I'd even risk the statement that it is quite wrongly implemented), when we have *no idea* if the slave copy is up2date or not.
Answers like those, make me think that open-source is a waste of time comparing to paid solutions (even though I am a strong evangelist of Debian and other open source solutions, which I think the writer does not care about).
Are you an engineer geek in the cellar? Stay there. Sorry, real world of *clearly* undocumented things.
Irritated night wishes.