On Sun, Dec 4, 2011 at 17:41, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.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/
