From: Tom Lane <tgl@sss.pgh.pa.us>
To: Magnus Hagander <magnus@hagander.net>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: PostgreSQL-documentation <pgsql-docs@postgresql.org>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Moving tablespaces
Date: Sun, 04 Dec 2011 11:41:30 -0500
Message-ID: <23636.1323016890@sss.pgh.pa.us> (raw)
In-Reply-To: <CABUevEzuRQLddyY2yypiZpjWzzEzz0p66TgzoXGuz+jLxKgdkg@mail.gmail.com>
References: <CABUevEx2xYV==WRxWdMr=mS3Q1orBUvJcXa8AZx_LVbL122g5Q@mail.gmail.com>
<201112041612.pB4GCHt06225@momjian.us>
<CABUevEzuRQLddyY2yypiZpjWzzEzz0p66TgzoXGuz+jLxKgdkg@mail.gmail.com>
Magnus Hagander <magnus@hagander.net> writes:
> And IIRC, we don't actually *use* spclocation anywhere.
Just for pg_dump, I think.
> How about we
> just get rid of them as independents? We could either:
> 1) Remove the column. Rely on the symlink. Create a
> pg_get_tablespace_location(oid) function, that could be used by
> pg_dumpall and friends, that just reads the symlink.
Hm, how portable is symlink-reading? If we can actually do that
without big headaches, then +1.
> 2) Forcibly update the spclocation column when we start the server to
> be whatever the symlink points to. That will at least automatically
> restore the system to being consistent.
-1, running a transaction at that level will be a giant pita.
And how would you do it at all on a hot standby slave?
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: tgl@sss.pgh.pa.us, magnus@hagander.net, bruce@momjian.us, pgsql-hackers@postgresql.org
Subject: Re: Moving tablespaces
In-Reply-To: <23636.1323016890@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox