Skip site navigation (1) Skip section navigation (2)

Re: Scanning pg_tablespace from walsender

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Scanning pg_tablespace from walsender
Date: 2011-01-03 16:17:58
Message-ID: 20110103161758.GJ4933@tamriel.snowman.net (view raw or flat)
Thread:
Lists: pgsql-hackers
* 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.

	Thanks,

		Stephen

In response to

Responses

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2011-01-03 16:19:25
Subject: Re: Scanning pg_tablespace from walsender
Previous:From: Magnus HaganderDate: 2011-01-03 16:17:30
Subject: Re: Scanning pg_tablespace from walsender

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group