Re: Support for N synchronous standby servers - take 2

On 19 July 2015 at 21:16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Josh Berkus <josh(at)agliodbs(dot)com> writes:
> > On 07/17/2015 04:36 PM, Jim Nasby wrote:
> >> I'm guessing it'd be really ugly/hard to support at least this GUC being
> >> multi-line?
>
> > Mind you, multi-line GUCs would be useful otherwise, but we don't want
> > to hinge this feature on making that work.
>
> I'm pretty sure that changing the GUC parser to allow quoted strings to
> continue across lines would be trivial.

Agreed

> The problem with it is not that
> it's hard, it's that omitting a closing quote mark would then result in
> the entire file being syntactically broken, with the error message(s)
> almost certainly pointing somewhere else than where the actual mistake is.
>

That depends upon how we specify line-continuation. If we do it with
starting and ending quotes, then we would have the problem you suggest. If
we required each new continuation line to start with a \ then it wouldn't
(or similar). Or perhaps it gets its own file even, an idea raised before.

Do we really want such a global reduction in friendliness to make this
> feature easier?
>

Clearly not, but we must first decide whether that is how we characterise
the decision.

synchronous_standby_name= is already 25 characters, so that leaves 115
characters - are they always single byte chars?

It's not black and white for me that JSON necessarily requires >115 chars
whereas other ways never will do.

What we are discussing is expanding an existing parameter to include more
information. If Josh gets some of the things he's been asking for, then the
format will bloat further. It doesn't take much for me to believe it might
expand further still, so my view from the discussion is that we'll likely
need to expand beyond 115 chars one day whatever format we choose.

I'm personally ambivalent what the exact format is that we choose; I care
much more about the feature than the syntax, always. My contribution so far
was to summarise what I thought was the majority opinion, and to challenge
the thought that JSON had no discernible benefit. If the majority view is
different, I have no problem there.

Clusters of 20 or more standby nodes are reasonably common, so those limits
do seem a little small. Synchronous commit behavior is far from being the
only cluster metadata we need to record. I'm thinking now that this
illustrates that this is the wrong way altogether and we should just be
storing cluster metadata in database tables, which is what was discussed
and agreed at the BDR meeting at PGCon.

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