On Mon, Jan 3, 2011 at 17:17, Stephen Frost <sfr...@snowman.net> wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Mon, Jan 3, 2011 at 10:42 AM, Magnus Hagander <mag...@hagander.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. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers