Re: Avoiding Tablespace path collision for primary and standby
От | Tom Lane |
---|---|
Тема | Re: Avoiding Tablespace path collision for primary and standby |
Дата | |
Msg-id | 26089.1527343737@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Avoiding Tablespace path collision for primary and standby (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: Avoiding Tablespace path collision for primary and standby
Re: Avoiding Tablespace path collision for primary and standby |
Список | pgsql-hackers |
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. Not sure about the relative-path idea. Seems like that would create a huge temptation to put tablespaces inside the data directory, which would force us to deal with that can of worms. Also, to the extent that people use tablespaces for what they're actually meant to be used for (ie, putting some stuff into a different filesystem), I can't see a relative path being helpful. Admins don't go mounting disks at random places in the filesystem tree. regards, tom lane
В списке pgsql-hackers по дате отправления: