Re: Support for N synchronous standby servers - take 2

On Wed, Feb 24, 2016 at 5:37 PM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> Hello,
>
> Ok, I think we should concentrate the parser part for now.
>
> At Tue, 23 Feb 2016 17:44:44 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote
in<20160223.174444.178687579.horiguchi.kyotaro@lab.ntt.co.jp>
 
>> Hello,
>>
>> At Mon, 22 Feb 2016 22:52:29 +0900, Fujii Masao <masao.fujii@gmail.com> wrote in
<CAHGQGwENujogaQvcc=u0tffNfFGtwXNb1yFcphdTYCJdG1_j1A@mail.gmail.com>
>> > Thanks for updating the patch!
>> >
>> > When I changed s_s_names to 'hoge*' and reloaded the configuration file,
>> > the server crashed unexpectedly with the following error message.
>> > This is obviously a bug.
>> >
>> >     FATAL:  syntax error
>>
>> I had a glance on the lexer part in the new patch.  It'd be
>> better to design the lexer from the beginning according to the
>> required behavior.
>>
>> The documentation for the syntax is saying as the following,
>>
>> http://www.postgresql.org/docs/current/static/runtime-config-logging.html
>>
>> > application_name (string)
>> >
>> > The application_name can be any string of less than NAMEDATALEN
>> > characters (64 characters in a standard build). <snip> Only
>> > printable ASCII characters may be used in the application_name
>> > value. Other characters will be replaced with question marks (?).
>>
>> And according to what some functions mentioned so far do, totally
>> an application_name is treated as follwoing, I suppose.
>>
>> - check_application_name() currently allows [\x20-\x7e], which
>>   differs from the definition of the SQL identifiers.
>>
>> - SplitIdentifierString() and syncrep code
>>
>>   - allows any byte except a double quote in double-quoted
>>    representation. A double-quote just after a delimiter can open
>>    quoted representation.
>>
>>   - Non-quoted name can contain any character including double
>>     quotes except ',' and white spaces.
>>
>>   - The syncrep code does case-insensitive matching with the
>>    application_name.
>>
>> So, to preserve or following the current behavior expct the last
>> one, the following pattern definitions would do. The
>> lexer/grammer for the new format of s_s_names could be simpler
>> than what it is.
>>
>> space                 [ \n\r\f\t\v] /* See the definition of isspace(3) */
>> whitespace            {space}+
>> dquote            \"
>> app_name_chars    [\x21-\x2b\x2d-\x7e]   /* excluding ' ', ',' */
>> app_name_indq_chars [\x20\x21\x23-\x7e]  /* excluding '"'  */
>> app_name_dq_chars ({app_name_indq_chars}|{dquote}{dquote})
>> delimiter         {whitespace}*,{whitespace}*
>> app_name  ({app_name_chars}+|{dquote}{app_name_dq_chars}+{dquote})
>> s_s_names {app_name}({delimiter}{app_name})*
>
>
> So I made a hasty independent parser for the syntax including the
> group names for the convenience for separate testing.  The parser
> takes input from stdin and prints the result structure.
>
> It can take old s_s_name format and new list format. We haven't
> discussed how to add gruop names but I added it as "<grpname>"
> just before the # of syncronous standbys of [] and {} lists.
>
> Is this usable for further discussions?

Thank you for your suggestion.

Another option is to add group name with ":" to immediately after set
of standbys as I said earlier.
<http://www.postgresql.org/message-id/CAD21AoA9UqcbTnDKi0osd0yhN4FPgTrg6wuZeTtvpSYy2LqL5Q@mail.gmail.com>

s_s_names with group name would be as follows.
s_s_names = '2[local, 2[london1, london2, london3]:london, (tokyo1,
tokyo2):tokyo]'

Though?

Regards,

--
Masahiko Sawada