Re: pg_basebackup creates a corrupt file for pg_stat_tmp and pg_replslot on a backup location
От | Andres Freund |
---|---|
Тема | Re: pg_basebackup creates a corrupt file for pg_stat_tmp and pg_replslot on a backup location |
Дата | |
Msg-id | 20160414190116.5jad7o4t3eumrnjl@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: pg_basebackup creates a corrupt file for pg_stat_tmp and pg_replslot on a backup location (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: pg_basebackup creates a corrupt file for pg_stat_tmp
and pg_replslot on a backup location
|
Список | pgsql-hackers |
On 2016-04-14 14:55:37 -0400, Robert Haas wrote: > On Thu, Apr 14, 2016 at 11:12 AM, Andres Freund <andres@anarazel.de> wrote: > > On 2016-04-14 13:43:34 +0530, Ashutosh Sharma wrote: > >> I tried performing pg_basebackup after creating a symbolic link for > >> pg_replslot, pg_stat_tmp, pg_log and pg_clog in the source directory > > > > That's not supported, and I strongly suspect that you're goint to hit > > more than just this issue. The only directory you're allowed to symlink > > away is pg_xlog. > > I think various tools might choke on such a configuration, but I'm not > entirely sure why we haven't made them all work. Is there some more > fundamental problem? I don't think there's a fundamental problem, just that it'd require adding code to numerous places, and that it'd make it harder to reason about things. For example you have to be a lot more careful about iterating over the data directory, because loops suddenly are a major concern. Fsyncing files & directories suddenly needs special care to fsync the correct directory for a file, lest it's symlinked somewhere. It's harder to perform checks like the "not at the top of the filesystem" when every file and directory can be somewhere else. - Andres
В списке pgsql-hackers по дате отправления: