Re: Re: pg_basebackup bug: base backup is double the size of the database
От | David Johnston |
---|---|
Тема | Re: Re: pg_basebackup bug: base backup is double the size of the database |
Дата | |
Msg-id | CAKFQuwYTpRw7q=AdZ2h6wdsab1BfJ+0oncO_ZHJzbDMWMy7ArA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: pg_basebackup bug: base backup is double the size of the database (Craig James <cjames@emolecules.com>) |
Список | pgsql-admin |
On Thursday, January 22, 2015, Craig James <cjames@emolecules.com> wrote:
On Wed, Jan 21, 2015 at 10:02 PM, David G Johnston <david.g.johnston@gmail.com> wrote:Craig James-2 wrote
> We've encountered a serious bug with pg_basebackup. It seems to be
> following hard links and duplicating all files in the tablespaces rather
> than preserving links.
This entire sentence doesn't make sense to me. How does one "follow" a
hard-link? A soft-link yes but a hard-link is an alias to actual data. I'm
not sure directory hard-linking is even allowed or used so following in that
sense don't compute...See the man page for rsync, the -H option, which explains it better:-H, --hard-linksThis tells rsync to look for hard-linked files in the transferand link together the corresponding files on the receiving side.Without this option, hard-linked files in the transfer aretreated as though they were separate files.
Which makes sense in a full system backup but a single-cluster backup should not (I think) have any situations where a file and a matching hard link are both within the same source structure. The -H option should not be needed because the scenario it solves is not expected to exist. That it does either means user error or a use-case that hasn't been considered. It seems improvements could be made here but a reliable test case describing the specific setup is needed first.
David J.
В списке pgsql-admin по дате отправления: