Re: Support for N synchronous standby servers - take 2

Robert Haas wrote:
> 
> On Thu, Jul 16, 2015 at 1:32 PM, Simon Riggs <simon@> wrote:
> >> Personally, I think we're going to find that using JSON for this
> >> rather than a custom syntax makes the configuration strings two or
> >> three times as long for
> >
> > They may well be 2-3 times as long. Why is that a negative?
> 
> In my opinion, brevity makes things easier to read and understand.  We
> also don't support multi-line GUCs, so if your configuration takes 140
> characters, you're going to have a very long line in your
> postgresql.conf (and in your pg_settings output, etc.)
> 
> > * No additional code required in the server to support this syntax (so
> no
> > bugs)
> 
> I think you'll find that this is far from true.  Presumably not any
> arbitrary JSON object will be acceptable.  You'll have to parse it as
> JSON, and then validate that it is of the expected form.  It may not
> be MORE code than implementing a mini-language from scratch, but I
> wouldn't expect to save much.
> 
> > * Developers will immediately understand the format
> 
> I doubt it.  I think any format that we pick will have to be carefully
> documented.  People may know what JSON looks like in general, but they
> will not immediately know what bells and whistles are available in
> this context.
> 
> * Easy to programmatically manipulate in a range of languages
> 
> I agree that JSON has that advantage, but I doubt that it is important
> here.  I would expect that people might need to generate a new config
> string and dump it into postgresql.conf, but that should be easy with
> any reasonable format.  I think it will be rare to need to parse the
> postgresql.conf string, manipulate it programatically, and then put it
> back.  As we've already said, most configurations are simple and
> shouldn't change frequently.  If they're not or they do, that's a
> problem of itself.
> 

All points here are valid and I would prefer a new language over JSON. I
agree, the new validation code would have to be properly tested to avoid
bugs but it wont be too difficult. 

Also I think methods that generate WAL record is avoided because any attempt
to change the syncrep settings will go in indefinite wait when a mandatory
sync candidate (as per current settings) goes down (Explained in earlier
post id: CAHGQGwE_-HCzw687B4SdMWqAkkPcu-uxmF3MKyDB9mu38cJ7Jg@mail.gmail.com)





-----
Beena Emerson

--
View this message in context:
http://postgresql.nabble.com/Support-for-N-synchronous-standby-servers-take-2-tp5849384p5858255.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.