Re: Scanning pg_tablespace from walsender - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Scanning pg_tablespace from walsender
Date
Msg-id 20110103161758.GJ4933@tamriel.snowman.net
Whole thread Raw
In response to Re: Scanning pg_tablespace from walsender  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Scanning pg_tablespace from walsender  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
* Robert Haas (robertmhaas@gmail.com) wrote:
> On Mon, Jan 3, 2011 at 10:42 AM, Magnus Hagander <magnus@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.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Scanning pg_tablespace from walsender
Next
From: Magnus Hagander
Date:
Subject: Re: Scanning pg_tablespace from walsender