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

Re: Scanning pg_tablespace from walsender

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Scanning pg_tablespace from walsender
Date: 2011-01-03 16:19:25
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.

 Magnus Hagander

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2011-01-03 16:20:38
Subject: Re: Streaming replication as a separate permissions
Previous:From: Stephen FrostDate: 2011-01-03 16:17:58
Subject: Re: Scanning pg_tablespace from walsender

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