Re: Regression test PANICs with master-standby setup on same machine

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Regression test PANICs with master-standby setup on same machine
Дата
Msg-id 20190423022706.GG2712@paquier.xyz
обсуждение исходный текст
Ответ на Regression test PANICs with master-standby setup on same machine  (Kuntal Ghosh <kuntalghosh.2007@gmail.com>)
Ответы Re: Regression test PANICs with master-standby setup on samemachine  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список pgsql-hackers
On Mon, Apr 22, 2019 at 03:52:59PM +0530, Kuntal Ghosh wrote:
> I accept that configuring master-standby on the same machine for this
> test is not okay. But, can we avoid the PANIC somehow? Or, is this
> intentional and I should not include testtablespace in this case?

Well, it is a bit more than "not okay", as the primary and the
standby step on each other's toe because they are trying to use the
same tablespace path.  The PANIC is also expected as that's what we
want with data_sync_retry = off, which is the default, and the wanted
behavior to PANIC immediately and enforce WAL recovery should a fsync
fail.  Obviously, not being able to have transparent tablespace
handling for multiple nodes on the same host is a problem, though this
implies grammar changes for CREATE TABLESPACE or having a sort of
node name handling which makes the experience trouble-less.  Still
there is the argument that not all users would want both instances to
use the same tablespace path.  So the problem is not as simple as it
looks, and the cost of solving it is not worth the use cases either.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: finding changed blocks using WAL scanning
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: standby recovery fails (tablespace related) (tentative patch anddiscussion)