Re: Support for N synchronous standby servers - take 2

On 5 April 2016 at 11:23, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

> On Tue, Apr 5, 2016 at 6:09 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> > On 5 April 2016 at 08:58, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
> > wrote:
> >
> >>
> >> >>>> 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.
>
> s/oldest/newest ?
>

Sure

> > 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.
>
> Yes. Probably we need to use some time to find what algorithm is the best
> for searching the k'th newest pointer.
>

I think we would all agree an insertion sort would be the fastest for k ~
2-5, no much discussion there.

We do already use that in this section of code, namely SHMQueue.

> > The syntax and doc changes would take a couple of
> > hours.
>
> Yes, the updates of documentation would need more time.
>

I can help, if you wish that.

"any k" is in my mind what people would be expecting us to deliver with
this feature, which is why I suggest it now, especially since it is a small
additional item.

Please don't see these comments as blocking your progress to commit.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services