On Wed, Jan 7, 2015 at 3:03 AM, Peter Eisentraut <pete...@gmx.net> wrote: > > On 12/27/14 8:02 PM, Robert Haas wrote: > > On Wed, Dec 24, 2014 at 8:12 AM, Peter Eisentraut <pete...@gmx.net> wrote: > >> On 12/22/14 10:00 PM, Amit Kapila wrote: > >>> There is already a patch [1] in this CF which will handle both cases, so > >>> I am > >>> not sure if it is very good idea to go with a new tar format to handle this > >>> issue. > >> > >> I think it would still make sense to have proper symlinks in the > >> basebackup if possible, for clarity. > > > > I guess I would have assumed it would be more clear to omit the > > symlinks if we're expecting the server to put them in. Otherwise, the > > server has to remove the existing symlinks and create new ones, which > > introduces various possibilities for failure and confusion. > > 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?
via some kind of tablespace map file which will tell us the exact location where symlink need to be pointed and the same will be used to create a symlink. So after you unpack a tarred basebackup with tablespaces, there will be no symlinks; when you start the server (archive recovery) using base backup, it will create the appropriate symlinks. > Secondly, you also have > the option of putting the tablespaces somewhere else by changing the > symlinks. Under the new scheme, the existing symlinks would be > overwritten (or not?). If that is actually correct, then the proposed > fix doesn't really replicate the required functionality on Windows. > > 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. > I think this is somewhat similar to what existing patch [1] does with the different that there is just one file for all the tablespace locations rather than individual file in each tablespace directory. [1] : https://commitfest.postgresql.org/action/patch_view?id=1512 With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
