On Sat, May 26, 2018 at 7:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Thomas Munro <thomas.munro@enterprisedb.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.
