Re: standby recovery fails (tablespace related) (tentative patchand discussion)

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: standby recovery fails (tablespace related) (tentative patchand discussion)
Дата
Msg-id 20190423.140234.163011296.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: standby recovery fails (tablespace related) (tentative patch anddiscussion)  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
At Tue, 23 Apr 2019 11:34:38 +0900, Michael Paquier <michael@paquier.xyz> wrote in <20190423023438.GH2712@paquier.xyz>
> On Mon, Apr 22, 2019 at 09:19:33PM +0900, Kyotaro HORIGUCHI wrote:
> > The attached exercises this sequence, needing some changes in
> > PostgresNode.pm and RecursiveCopy.pm to allow tablespaces.
> 
> +    # Check for symlink -- needed only on source dir
> +    # (note: this will fall through quietly if file is already gone)
> +    if (-l $srcpath)
> +    {
> +        croak "Cannot operate on symlink \"$srcpath\""
> +          if ($srcpath !~ /\/(pg_tblspc\/[0-9]+)$/);
> +
> +        # We have mapped tablespaces. Copy them individually
> +        my $linkname = $1;
> +        my $tmpdir = TestLib::tempdir;
> +        my $dstrealdir = TestLib::real_dir($tmpdir);
> +        my $srcrealdir = readlink($srcpath);
> +
> +        opendir(my $dh, $srcrealdir);
> +        while (readdir $dh)
> +        {
> +            next if (/^\.\.?$/);
> +            my $spath = "$srcrealdir/$_";
> +            my $dpath = "$dstrealdir/$_";
> +
> +            copypath($spath, $dpath);
> +        }
> +        closedir $dh;
> +
> +        symlink $dstrealdir, $destpath;
> +        return 1;
> +    }
> 
> The same stuff is proposed here:
> https://www.postgresql.org/message-id/CAGRcZQUxd9YOfifOKXOfJ+Fp3JdpoeKCzt+zH_PRMNaaDaExdQ@mail.gmail.com
> 
> So there is a lot of demand for making the recursive copy more skilled
> at handling symlinks for tablespace tests, and I'd like to propose to
> do something among those lines for the tests on HEAD, presumably for
> v12 and not v13 as we are talking about a bug fix here?  I am not sure
> yet which one of the proposals is better than the other though.

TBH I like that (my one cieted above) not so much. However, I
prefer to have v12 if this is a bug and to be fixed in
v12. Otherwise we won't add a test for this later:p

Anyway I'll visit there. Thanks. 

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: REINDEX INDEX results in a crash for an index of pg_class since9.6
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: [PATCH v1] Show whether tables are logged in \dt+