Affects: Server-7.1   —   Status: Un-Assigned   —   Priority: Medium

Came after discussion with one of our important support customers (contact
Guilhem Bichot for the name).

We currently feature START SLAVE UNTIL [coordinates] where slave SQL thread will
stop when it is at or beyond the coordinates. If slave SQL thread is already
started, a warning is issued and nothing is done (slave SQL thread is not
stopped even if it's at or beyond the coordinates).

This command can be used to do master/slave synchronization, but the stop which
occurs is sometimes undesirable (especially if there are automated scripts
monitoring that the slave SQL thread is running, those scripts would send
superfluous alarms - the is the case of our customer).

The idea would be to:
1) add clauses AND STOP and AND BLOCK to START SLAVE UNTIL. AND STOP would be
noise. AND BLOCK would not cause the slave SQL thread to stop but rather to
suspend execution of replication events as soon as it is at or beyond
coordinates: the slave SQL thread would be reported as "running", but would be
sleeping. Disconnection of the session which issued the START SLAVE command, or
issuing a START SLAVE in the same session, would unblock the slave SQL thread.
Note that if a 2nd thread issues START SLAVE AND BLOCK while the first has
blocked slave, the slave should not be unblocked: slave should unblock only when
first thread decides to unblock, and then the request of the 2nd thread will be
processed; until then, that request will hang (indicated by customer); like a
mutex lock.
2) change the behaviour so that UNTIL (and AND STOP|BLOCK) is applied even if
the slave SQL thread is already started. For consistency.

Lars thinks that it would be better to change the monitoring 
software to check *why* the slave has stopped, and possibly 
extend the slave reporting mechanism for this.