At Tue, 23 Apr 2019 13:33:39 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote in <20190423.133339.113770648.horiguchi.kyot...@lab.ntt.co.jp> > At Tue, 23 Apr 2019 11:27:06 +0900, Michael Paquier <mich...@paquier.xyz> > wrote in <20190423022706.gg2...@paquier.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
all paths out of $PGDATA directory. tablespace locations, log_directory and stats_temp_directory? > something more generic than tablespace_chroot. > > Does it make sense? -- Kyotaro Horiguchi NTT Open Source Software Center
