Hi, On 2019-04-24 10:13:09 -0400, Tom Lane wrote: > Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> writes: > > At Wed, 24 Apr 2019 13:23:04 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI > > <horiguchi.kyot...@lab.ntt.co.jp> wrote in > > <20190424.132304.40676137.horiguchi.kyot...@lab.ntt.co.jp> > >> We need to adjust relative path between PGDATA-based and > >> pg_tblspc based. The attached first patch does that. > > > This is new version. Adjusted pg_basebackup's behavior to allow > > relative mappings. But.. > > I can't say that I like 0001 at all. It adds a bunch of complication and > new failure modes (e.g., having to panic on chdir failure) in order to do > what exactly? I've not been following the thread closely, but the > original problem is surely just a dont-do-that misconfiguration. I also > suspect that this is assuming way too much about the semantics of getcwd > --- some filesystem configurations may have funny situations like multiple > paths to the same place.
I'm not at all defending the conrete patch. But I think allowing relative paths to tablespaces would solve a whole lot of practical problems, while not meaningfully increasing failure modes. The inability to reasonably test master/standby setups on a single machine is pretty jarring (yes, one can use basebackup tablespace maps - but that doesn't work well for new tablespaces). And for a lot of production setups absolute paths suck too - it's far from a given that primary / standby databases need to have the same exact path layout. Greetings, Andres Freund