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

Re: Scanning pg_tablespace from walsender

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:14:26
Message-ID: 20218.1294071266@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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.

Well, you're quietly ignoring a whole bunch of issues there, like
whether the tablespaces *should* be in the identical locations on the
other machine and how you'll deal with it if not.  Eventually there's
going to need to be some sort of "tablespace mapping" option for
replication.  But anyway, taking a base backup is fundamentally defined
as "scan the filesystem, paying no attention to catalogs" and ISTM that
it obviously should be the same way for tablespaces.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2011-01-03 16:17:30
Subject: Re: Scanning pg_tablespace from walsender
Previous:From: Heikki LinnakangasDate: 2011-01-03 16:08:51
Subject: Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid

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