Re: pg_basebackup fails with long tablespace paths
От | Robert Haas |
---|---|
Тема | Re: pg_basebackup fails with long tablespace paths |
Дата | |
Msg-id | CA+Tgmob5b7-hFdJKHEHvhHqY5DchC0TGRDR+9EOLN2cmte+nkg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_basebackup fails with long tablespace paths (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: pg_basebackup fails with long tablespace paths
|
Список | pgsql-hackers |
On Tue, Jan 6, 2015 at 4:33 PM, Peter Eisentraut <peter_e@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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: