Re: Support for N synchronous standby servers - take 2

On Tue, Apr 12, 2016 at 9:04 AM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> On Mon, Apr 11, 2016 at 8:47 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Mon, Apr 11, 2016 at 5:52 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>>> On Mon, Apr 11, 2016 at 1:31 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>>> On Mon, Apr 11, 2016 at 10:58 AM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>>>>> On Sat, Apr 9, 2016 at 12:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>>>> Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
>>>>>>> When I compile now without cassert, I get the compiler warning:
>>>>>>
>>>>>>> syncrep.c: In function 'SyncRepUpdateConfig':
>>>>>>> syncrep.c:878:6: warning: variable 'parse_rc' set but not used
>>>>>>> [-Wunused-but-set-variable]
>>>>>>
>>>>>> If there's a good reason for that to be an Assert, I don't see it.
>>>>>> There are no callers of SyncRepUpdateConfig that look like they
>>>>>> need to, or should expect not to have to, tolerate errors.
>>>>>> I think the way to fix this is to turn the Assert into a plain
>>>>>> old test-and-ereport-ERROR.
>>>>>>
>>>>>
>>>>> I've changed the draft patch Amit implemented so that it doesn't parse
>>>>> twice(check_hook and assign_hook).
>>>>> So assertion that was in assign_hook is no longer necessary.
>>>>>
>>>>> Please find attached.
>>>>
>>>> Thanks for the patch!
>>>>
>>>> When I emptied s_s_names, reloaded the configration file, set it to 'standby1'
>>>> and reloaded the configuration file again, the master crashed with
>>>> the following error.
>>>>
>>>> *** glibc detected *** postgres: wal sender process postgres [local]
>>>> streaming 0/3015F18: munmap_chunk(): invalid pointer:
>>>> 0x00000000024d9a40 ***
>>>> ======= Backtrace: =========
>>>> *** glibc detected *** postgres: wal sender process postgres [local]
>>>> streaming 0/3015F18: munmap_chunk(): invalid pointer:
>>>> 0x00000000024d9a40 ***
>>>> /lib64/libc.so.6[0x3be8e75f4e]
>>>> postgres: wal sender process postgres [local] streaming 0/3015F18[0x97dae2]
>>>> ======= Backtrace: =========
>>>> /lib64/libc.so.6[0x3be8e75f4e]
>>>> postgres: wal sender process postgres [local] streaming
>>>> 0/3015F18(set_config_option+0x12cb)[0x982242]
>>>> postgres: wal sender process postgres [local] streaming
>>>> 0/3015F18(SetConfigOption+0x4b)[0x9827ff]
>>>> postgres: wal sender process postgres [local] streaming 0/3015F18[0x97dae2]
>>>> postgres: wal sender process postgres [local] streaming 0/3015F18[0x988b4e]
>>>> postgres: wal sender process postgres [local] streaming
>>>> 0/3015F18(set_config_option+0x12cb)[0x982242]
>>>> postgres: wal sender process postgres [local] streaming 0/3015F18[0x98af40]
>>>> postgres: wal sender process postgres [local] streaming
>>>> 0/3015F18(SetConfigOption+0x4b)[0x9827ff]
>>>> postgres: wal sender process postgres [local] streaming
>>>> 0/3015F18(ProcessConfigFile+0x9f)[0x98a98b]
>>>> postgres: wal sender process postgres [local] streaming 0/3015F18[0x988b4e]
>>>> postgres: wal sender process postgres [local] streaming 0/3015F18[0x98af40]
>>>> postgres: wal sender process postgres [local] streaming 0/3015F18[0x7b50fd]
>>>> postgres: wal sender process postgres [local] streaming
>>>> 0/3015F18(ProcessConfigFile+0x9f)[0x98a98b]
>>>> postgres: wal sender process postgres [local] streaming 0/3015F18[0x7b359c]
>>>> postgres: wal sender process postgres [local] streaming 0/3015F18[0x7b50fd]
>>>> postgres: wal sender process postgres [local] streaming
>>>> 0/3015F18(exec_replication_command+0x1a7)[0x7b47b6]
>>>> postgres: wal sender process postgres [local] streaming 0/3015F18[0x7b359c]
>>>> postgres: wal sender process postgres [local] streaming
>>>> 0/3015F18(PostgresMain+0x772)[0x8141b6]
>>>> postgres: wal sender process postgres [local] streaming
>>>> 0/3015F18(exec_replication_command+0x1a7)[0x7b47b6]
>>>> postgres: wal sender process postgres [local] streaming 0/3015F18[0x7896f7]
>>>> postgres: wal sender process postgres [local] streaming
>>>> 0/3015F18(PostgresMain+0x772)[0x8141b6]
>>>> postgres: wal sender process postgres [local] streaming 0/3015F18[0x788e62]
>>>> postgres: wal sender process postgres [local] streaming 0/3015F18[0x7896f7]
>>>> postgres: wal sender process postgres [local] streaming 0/3015F18[0x785544]
>>>> postgres: wal sender process postgres [local] streaming 0/3015F18[0x788e62]
>>>> postgres: wal sender process postgres [local] streaming
>>>> 0/3015F18(PostmasterMain+0x1134)[0x784c08]
>>>> postgres: wal sender process postgres [local] streaming 0/3015F18[0x785544]
>>>> postgres: wal sender process postgres [local] streaming 0/3015F18[0x6ce12e]
>>>> /lib64/libc.so.6(__libc_start_main+0xfd)[0x3be8e1ed5d]
>>>> postgres: wal sender process postgres [local] streaming
>>>> 0/3015F18(PostmasterMain+0x1134)[0x784c08]
>>>> postgres: wal sender process postgres [local] streaming 0/3015F18[0x467e99]
>>>>
>>>
>>> Thank you for reviewing.
>>>
>>> SyncRepUpdateConfig() seems to be no longer necessary.
>>
>> Really? I was thinking that something like that function needs to
>> be called at the beginning of a backend and walsender in
>> EXEC_BACKEND case. No?
>>
>
> Hmm, in EXEC_BACKEND case, I guess that each child process calls
> read_nondefault_variables that parses and validates these
> configuration parameters in SubPostmasterMain.

SyncRepStandbyNames is passed but SyncRepConfig is not, I think.

Regards,

--
Fujii Masao