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 something more generic than tablespace_chroot. Does it make sense? regards. -- Kyotaro Horiguchi NTT Open Source Software Center
