Re: Support for N synchronous standby servers - take 2

Hello,

At Wed, 27 Apr 2016 18:05:26 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <3167(dot)1461794726(at)sss(dot)pgh(dot)pa(dot)us>
> Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> > Sorry, I have attached an empty patch. This is another one that should
> > be with content.
>
> I pushed this after whacking it around some, and cleaning up some
> sort-of-related problems in the syncrep parser/lexer.

Thank you for pushing this (with improvements) and improvements
of synchronous_standby_names. I agree to the discussion that
standby names should have restriction not to break possible
extension to be happen near future.

> There remains a point that I'm not very happy about, which is the code
> in check_synchronous_standby_names to emit a WARNING if the num_sync
> setting is too large. That's a pretty bad compromise: we should either
> decide that the case is legal or that it is not. If it's legal, people
> who are correctly using the case will not thank us for logging a WARNING
> every single time the postmaster gets a SIGHUP (and those who aren't using
> it correctly will have their systems freezing up, warning or no warning).
> If it's not legal, we should make it an error not a warning.

This specification makes the code a bit complex and makes the
document a bit less understandable. It seems to me somewhat
suspicious that allowing duplcate (potentially synchronous)
walrecivers is so useful as to justify such disadvantages.

In spite of this, my inclination is also the same as the
following:p rather than making the behavior consistent and clear.

> My inclination is to just rip out the warning.

Is there anyone object to removing the warining?

> But I wonder whether the
> desire to have one doesn't imply that the semantics are poorly chosen
> and should be revisited.

We already have abandoned a bit of backward compatibility in this
feature.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center