Re: Support for N synchronous standby servers - take 2 - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: Support for N synchronous standby servers - take 2
Date
Msg-id 55ABFE78.8070208@agliodbs.com
Whole thread Raw
In response to Re: Support for N synchronous standby servers - take 2  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Support for N synchronous standby servers - take 2  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 07/17/2015 04:36 PM, Jim Nasby wrote:
> On 7/16/15 12:40 PM, Robert Haas wrote:
>>> >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.)
> 
> Brevity goes both ways, but I don't think that's the real problem here;
> it's the lack of multi-line support. The JSON that's been proposed makes
> you work really hard to track what level of nesting you're at, while
> every alternative format I've seen is terse enough to be very clear on a
> single line.

I will point out that the proposed non-JSON syntax does not offer any
ability to name consensus/priority groups.  I believe that being able to
name groups is vital to managing any complex synch rep, but if we add
names it will make the non-JSON syntax less compact.

> 
> I'm guessing it'd be really ugly/hard to support at least this GUC being
> multi-line?

Yes.

Mind you, multi-line GUCs would be useful otherwise, but we don't want
to hinge this feature on making that work.


-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Implementation of global temporary tables?
Next
From: Noah Misch
Date:
Subject: xlc 12.1 miscompiles 32-bit ginCompareItemPointers()