Re: pg_basebackup creates a corrupt file for pg_stat_tmp and pg_replslot on a backup location

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

In response to

Browse pgsql-hackers by date

  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