On Mon, Jan 3, 2011 at 17:17, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> On Mon, Jan 3, 2011 at 10:42 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> > Well, they need to be put back in the same location on the other
>> > machine (slave in case of replication, tarball otherwise). If I just
>> > traverse the symlinks, they'll just appears as a subdirectory of
>> > pg_tblspc on the other machine, won't they?
>> Sure, I guess you'd need to read the links if you want it to work that way.
> Have to admit, I'm not entirely sure if this is really the behavior that
> makes the most sense. My gut reaction to this is that it'd make more
> sense for them to end up as directories rather than symlinks to places
> that might not exist on the slave, or that might not be writable by PG
> on the slave. I can see arguments either way though and so I really
> don't like the idea of it being forced one way or the other.
> Here's my 2c- make it optional on the slave side and then don't complain
> if the symlink already exists (even if it goes somewhere else). My
> thinking is that if someone needs to have the tablespaces reside
> somewhere else on the slave, they could say "don't create the symlinks"
> in the recovery config, and then manually create the symlinks where they
> need them to go.
It's already a basic requirement that they need to be the same -
replicating over a CREATE TABLESPACE is going to fail otherwise..
Being able to deal with that in a nice way would be good, of course,
but we don't have that today.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2011-01-03 16:20:38|
|Subject: Re: Streaming replication as a separate permissions |
|Previous:||From: Stephen Frost||Date: 2011-01-03 16:17:58|
|Subject: Re: Scanning pg_tablespace from walsender|