>>>> So I am suggesting we put an extra keyword in front of the “k”, to > explain how the k responses should be gathered as an extension to the the > syntax. I also think implementing “any k” is actually fairly trivial and > could be done for 9.6 (rather than just "first k").
+1 for 'first/any k (...)', with possibly only 'first' supported for now, if the 'any' case is more involved than we would like to spend time on, given the time considerations. IMHO, the extra keyword adds to clarity of the syntax.
Further thoughts:
I said "any k" was faster, though what I mean is both faster and more robust. If you have network peaks from any of the k sync standbys then the user will wait longer. With "any k", if a network peak occurs, then another standby response will work just as well. So the performance of "any k" will be both faster, more consistent and less prone to misconfiguration.
I also didn't explain why I think it is easy to implement "any k".
All we need to do is change SyncRepGetOldestSyncRecPtr() so that it returns the k'th oldest pointer of any named standby. Then use that to wake up user backends. So the change requires only slightly modified logic in a very isolated part of the code, almost all of which would be code inserts to cope with the new option. The syntax and doc changes would take a couple of hours.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services