From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_basebackup creates a corrupt file for pg_stat_tmp and pg_replslot on a backup location |
Date: | 2016-04-14 19:13:11 |
Message-ID: | 570FEBC7.7080108@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 4/14/16 3:01 PM, Andres Freund wrote:
> On 2016-04-14 14:55:37 -0400, Robert Haas wrote:
>> On Thu, Apr 14, 2016 at 11:12 AM, Andres Freund <andres(at)anarazel(dot)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?
>
> <...> Fsyncing files & directories suddenly needs special care to
> fsync the correct directory for a file, lest it's symlinked somewhere.
That's a good point. I'll need to make sure pgBackRest is correctly
handling that case on restore.
--
-David
david(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2016-04-14 19:42:10 | Memory leak when querying GIN indexes |
Previous Message | David Steele | 2016-04-14 19:08:24 | Re: pg_basebackup creates a corrupt file for pg_stat_tmp and pg_replslot on a backup location |