Re: Bug with pg_basebackup and 'shared' tablespace

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: p(dot)psql(at)pinaraf(dot)info
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bug with pg_basebackup and 'shared' tablespace
Date: 2017-05-12 07:24:12
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hi, I noticed this just now.

At Mon, 01 May 2017 19:28:59 +0200, Pierre Ducroquet <p(dot)psql(at)pinaraf(dot)info> wrote in <05c62730-8670-4da6-b783-52e66fb42232(at)pinaraf(dot)info>
> 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.

My concern is the behavior different from server, it accepts
existing catver directory if it is empty.

Anyway, I think it's better that ReceiveAndUnpackTarFile()
doesn't accept any existing direcotry.


Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2017-05-12 07:26:19 Re: multi-column range partition constraint
Previous Message Amit Kapila 2017-05-12 07:07:43 Re: UPDATE of partition key