Re: Avoiding Tablespace path collision for primary and standby - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Avoiding Tablespace path collision for primary and standby
Date
Msg-id 26089.1527343737@sss.pgh.pa.us
Whole thread Raw
In response to Re: Avoiding Tablespace path collision for primary and standby  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses 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>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: SPI/backend equivalent of extended-query Describe(statement)?
Next
From: Michael Paquier
Date:
Subject: Re: SCRAM with channel binding downgrade attack