On 1/7/15 3:19 PM, Robert Haas wrote: > On Tue, Jan 6, 2015 at 4:33 PM, Peter Eisentraut <pete...@gmx.net> wrote: >> Currently, when you unpack a tarred basebackup with tablespaces, the >> symlinks will tell you whether you have unpacked the tablespace tars at >> the right place. Otherwise, how do you know? Secondly, you also have >> the option of putting the tablespaces somewhere else by changing the >> symlinks. > > That's a good argument for making the tablespace-map file > human-readable and human-editable, but I don't think it's an argument > for duplicating its contents inaccurately in the filesystem. > >> One way to address this would be to do away with the symlinks altogether >> and have pg_tblspc/12345 be a text file that contains the tablespace >> location. Kind of symlinks implemented in user space. > > Well, that's just spreading the tablespace-map file out into several > files, and maybe keeping it around after we've restored from backup.
I think the key point I'm approaching is that the information should only ever be in one place, all the time. This is not dissimilar from why we took the tablespace location out of the system catalogs. Users might have all kinds of workflows for how they back up, restore, and move their tablespaces. This works pretty well right now, because the authoritative configuration information is always in plain view. The proposal is essentially that we add another location for this information, because the existing location is incompatible with some operating system tools. And, when considered by a user, that second location might or might not collide with or overwrite the first location at some mysterious times. So I think the preferable fix is not to add a second location, but to make the first location compatible with said operating system tools, possibly in the way I propose above. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers