Re: Streaming basebackups vs pg_stat_tmp - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Streaming basebackups vs pg_stat_tmp
Date
Msg-id CABUevEy2RycbcykpKxM1fPtWu+rgnQDgWOptzL-Lj-VbHgyOQA@mail.gmail.com
Whole thread Raw
In response to Re: Streaming basebackups vs pg_stat_tmp  (David Steele <david@pgmasters.net>)
Responses Re: Streaming basebackups vs pg_stat_tmp
List pgsql-hackers
On Fri, Oct 28, 2016 at 2:44 PM, David Steele <david@pgmasters.net> wrote:
On 10/28/16 11:53 AM, Magnus Hagander wrote:
In 9.6 and earlier, if you change pg_stat_tmp to be a symlink,
basebackups no longer work. That's because we create symlink entry in
the tarfile for it instead of an empty directory, but with no data,
which Breaks Everything (TM).

This was fixed in head in 6ad8ac60, which introduced "more excludes",
due to the refactoring. That commit message refers to it also fixing
this bug, but it seems the bugfix was never backpatched.

Or did I miss something?

I don't think so.  I guess it got lost in the CF rush and also slipped my mind when I reviewed the final commit.

Attached patch fixds this (based on 9.5 which is where I ran into it,
but it needs to go in other back branches as well) by bringing back a
(modified) version of the functoin _tarWriteDir() to the back branches.

I'd appreciate a look-over before committing, but it works fine in my tests.

The patch looks sane to me, but I think it would be good to backpatch the TAP test from the exclusion patch that tests pg_replslot as a symlink.

So that's the test that's in that same patch, 6ad8ac60, right? How much of the code for that is actually needed? (like the row which changes a 10 to a 11? which probably means something, but is it relevant here?) Or all of it? 

--

pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Danger of automatic connection reset in psql
Next
From: Robert Haas
Date:
Subject: Re: Query regarding selectDumpableExtension()