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  (Ashwin Agrawal <aagrawal@pivotal.io>)
Re: Avoiding Tablespace path collision for primary and standby  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: SPI/backend equivalent of extended-query Describe(statement)?
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: SCRAM with channel binding downgrade attack