Hi,
On 2019-04-24 10:13:09 -0400, Tom Lane wrote:
> Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:
> > At Wed, 24 Apr 2019 13:23:04 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote
in<20190424.132304.40676137.horiguchi.kyotaro@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