Re: Moving tablespaces

On Sun, Dec 4, 2011 at 17:41, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> And IIRC, we don't actually *use* spclocation anywhere.
>
> Just for pg_dump, I think.

pg_dumpall :-)

It's also used in pg_upgrade and pg_basebackup, but those are easily
dealt with if we define a function for it.

>> 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.

We already use readlink in a couple of places - including getting
called from find_my_exec. It's also used in pg_basebackup. The use in
find_my_exec is conditional on HAVE_READLINK, but not the one in
backend/replication/basebackup.c. An oversight from my side when
putting that in, but it shows that every single bf member we have now
has readlink - else the whole compilation would fail, AFAICT.

It's not directly portable to win32, but we have a wrapper function
for it in port/ already.

So I think we're fairly committed to having readlink already.

>> 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?

yeah, it would break that usage scenario, so I'm -1 for that one as well.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/