On Sun, Dec 4, 2011 at 17:41, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
