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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] PostgresNode::poll_query_until hacking
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Race-like failure in recovery/t/009_twophase.pl