Re: Streaming basebackups vs pg_stat_tmp

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Streaming basebackups vs pg_stat_tmp
Дата
Msg-id CABUevEy2RycbcykpKxM1fPtWu+rgnQDgWOptzL-Lj-VbHgyOQA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Streaming basebackups vs pg_stat_tmp  (David Steele <david@pgmasters.net>)
Ответы Re: Streaming basebackups vs pg_stat_tmp  (David Steele <david@pgmasters.net>)
Список 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 по дате отправления:

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Danger of automatic connection reset in psql
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Query regarding selectDumpableExtension()