Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl
| От | Michael Paquier |
|---|---|
| Тема | Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl |
| Дата | |
| Msg-id | CAB7nPqSOFT7Tg8Qk+tkzXZezWPbcc4THr924mHb1+PMN55RbxA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl
|
| Список | pgsql-hackers |
(catching up test threads) On Mon, Jul 3, 2017 at 7:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I'm now inclined to think that the correct fix is to ensure that we > run synchronous rep in both directions, rather than to insert delays > to substitute for that. Just setting synchronous_standby_names for > node paris at the top of the script doesn't work, because there's > at least one place where the script intentionally issues commands > to paris while london is stopped. I bet that using syncrep in both directions will likely avoid inconsistencies in the future if the test suite is extended on way or another. > But we could turn off sync rep for that step, perhaps. Yeah, by using synchronous_commit = off. > Anyone have a different view of what to fix here? No, this sounds like a good plan. What do you think about the attached? -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: