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

At Tue, 23 Apr 2019 11:27:06 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in <20190423022706(dot)GG2712(at)paquier(dot)xyz>
> 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.

We could easily adopt a jail or chroot like feature to tablespace
paths. Suppose a new GUC(!), say, tablespace_chroot and the value
can contain replacements like %a, %p, %h, we would set the
variable as:

tablespace_chroot = '/somewhere/%p';

then the tablespace location is prefixed by '/somewhere/5432' for
the first server, '/somehwere/5433' for the second.

I think this is rahter a testing or debugging feature. This can
be apply to all paths, so the variable might be "path_prefix" or
something more generic than tablespace_chroot.

Does it make sense?

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center