On Friday, April 7, 2017 3:12:58 AM CEST, Kyotaro HORIGUCHI wrote:
> Hi, Pierre.
>
> Maybe you're the winner:p
>
> At Thu, 06 Apr 2017 12:34:09 +0200, Pierre Ducroquet
> <p.psql@pinaraf.info> wrote in <1714428.BHRm6e8A2D@peanuts2>
>> On Thursday, April 6, 2017 2:00:55 PM CEST Kyotaro HORIGUCHI wrote: ...
>
> That being said, it is a different matter if the behavior is
> preferable. The discussion on the behavior is continued here.
>
> https://www.postgresql.org/message-id/20170406.160844.120459562.horiguchi.kyotaro@lab.ntt.co.jp
>
>> Right now, there is a conflict between pg_basebackup and the
>> server since they
>> do not allow the same behaviour. I can submit a patch either
>> way, but I won't
>> decide what is the right way to do it.
>> I know tricks will allow to work around that issue, I found
>> them hopefully and
>> I guess most people affected by this issue would be able to
>> find and use them,
>> but nevertheless being able to build a server that can no longer be base-
>> backuped does not seem right.
>
> regards,
Hi
I didn't have much time to spend on that issue until today, and I found a
way to solve it that seems acceptable to me.
The biggest drawback will be that if the backup is interrupted, previous
tablespaces already copied will stay on disk, but since that issue could
already happen, I don't think it's too much a drawback.
The patch simply delays the empty folder checking until we start reading
the tablespace tarball. The first entry of the tarball being the
PG_MAJOR_CATVER folder, that can not be found otherwise, there is no real
alternative to that.
I will submit this patch in the current commit fest.
Regards
Pierre
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
