Re: Avoiding Tablespace path collision for primary and standby

On Sat, May 26, 2018 at 7:08 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> > I also wondered about this when trying to figure out how to write a
> > TAP test for recovery testing with tablespaces, for my undo proposal.
> > I was starting to wonder about either allowing relative paths or
> > supporting some kind of variable in the tablespace path that could
> > then be set differently in each cluster's .conf.
>
> Yeah, the configuration-variable solution had occurred to me too.
> I'm not sure how convenient it'd be in practice, but perhaps it
> would be workable.
>

Configuration variable becomes tricky to play with for this purpose,
specially given configuration files get copied by pg_basebackup.
Will the configuration-variable be set by some option to pg_basebackup, as
even during pg_basebackup will need to use the same configuration-variable.
(I know basebackup provides way to specify different path for existing
tablespaces but seems will need to still use same static string for ALL the
tablespaces path, given how the linking and directory creation happens
today)

Also, not sure how configuration-variable will be used to solve the
problem, like changing its value shouldn't block me from accessing the
previously created tablespaces and all.

Seems as the conflict happens naturally by design, if it can be resolved
someway automatically would be better than a config option based solution.