Re: Re: pg_basebackup bug: base backup is double the size of the database

On Thursday, January 22, 2015, Craig James <cjames(at)emolecules(dot)com> wrote:

>
>
> On Wed, Jan 21, 2015 at 10:02 PM, David G Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com
> <javascript:_e(%7B%7D,'cvml','david(dot)g(dot)johnston(at)gmail(dot)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-links
> This tells rsync to look for hard-linked files in the
> transfer
> and link together the corresponding files on the receiving
> side.
> Without this option, hard-linked files in the transfer
> are
> treated 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.