Re: Regression test PANICs with master-standby setup on same machine - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Regression test PANICs with master-standby setup on same machine
Date
Msg-id 20190423022706.GG2712@paquier.xyz
Whole thread Raw
In response to Regression test PANICs with master-standby setup on same machine  (Kuntal Ghosh <kuntalghosh.2007@gmail.com>)
Responses Re: Regression test PANICs with master-standby setup on samemachine
List 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

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: finding changed blocks using WAL scanning
Next
From: Michael Paquier
Date:
Subject: Re: standby recovery fails (tablespace related) (tentative patch anddiscussion)