Re: Support for N synchronous standby servers - take 2 - Mailing list pgsql-hackers
From | Masahiko Sawada |
---|---|
Subject | Re: Support for N synchronous standby servers - take 2 |
Date | |
Msg-id | CAD21AoDSh4eVUVARf47zUFk1Bq57pUB+C=9NZtLh8Hw6Ru_KWg@mail.gmail.com Whole thread Raw |
In response to | Re: Support for N synchronous standby servers - take 2 (Fujii Masao <masao.fujii@gmail.com>) |
Responses |
Re: Support for N synchronous standby servers - take 2
(Fujii Masao <masao.fujii@gmail.com>)
|
List | pgsql-hackers |
On Mon, Apr 11, 2016 at 8:47 PM, Fujii Masao <masao.fujii@gmail.com> wrote: > On Mon, Apr 11, 2016 at 5:52 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote: >> On Mon, Apr 11, 2016 at 1:31 PM, Fujii Masao <masao.fujii@gmail.com> wrote: >>> On Mon, Apr 11, 2016 at 10:58 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote: >>>> On Sat, Apr 9, 2016 at 12:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>>> Jeff Janes <jeff.janes@gmail.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. Previous patch didn't apply to HEAD cleanly, attached updated version. Regards, -- Masahiko Sawada
Attachment
pgsql-hackers by date: