On Mon, Jan 3, 2011 at 17:14, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> 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.
>
> 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.
I'm doing that now, and it works fine on my linux box. Haven't looked
at a win32 implementation yet, but that can certainly be done.
As for relocating tablespaces - yes, that would be very useful. But at
this point, we *do* require them to be at the same place on the box
you restore to (whether it's a backup or a slave).
That said, it seems we don't actually ever *care* - from my quick grep
of the source, it seems we never ever read the location from the
catalog - we just store it there for reference. So in theory, we
should be able to relocate a tablespace by just changing the symlink.
But that would leave pg_tablespace and the filesystem out of sync, so
we probably shouldn't do that.
Either way, relocating tablespaces is for the future, let's start with
being able to do streaming base backups at all.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
