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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Regression test PANICs with master-standby setup on same machine
Date: 2019-04-23 02:27:06
Message-ID: 20190423022706.GG2712@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-04-23 02:34:38 Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Previous Message Robert Haas 2019-04-23 01:51:33 Re: finding changed blocks using WAL scanning