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-04-07 01:12:58
Message-ID: 20170407.101258.17219966.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi, Pierre.

Maybe you're the winner:p

At Thu, 06 Apr 2017 12:34:09 +0200, Pierre Ducroquet <p(dot)psql(at)pinaraf(dot)info> wrote in <1714428(dot)BHRm6e8A2D(at)peanuts2>
> On Thursday, April 6, 2017 2:00:55 PM CEST Kyotaro HORIGUCHI wrote:
> > https://www.postgresql.org/docs/9.6/static/manage-ag-tablespaces.html
> >
> > | The location must be an existing, empty directory that is owned
> > | by the PostgreSQL operating system user.
> >
> > This explicitly prohibits to share one tablespace directory among
> > multiple servers. The code is just missing the case of multiple
> > servers with different versions. I think the bug is rather that
> > Pg9.6 in the case allowed to create the tablespace.
> >
> > The current naming rule of tablespace directory was introduced as
> > of 9.0 so that pg_upgrade (or pg_migrator at the time) can
> > perform in-place migration. It is not intended to share a
> > directory among multiple instances with different versions.
> >
> > That being said, an additional trick in the attached file will
> > work for you.
>
> Thanks for your answer.
> Indeed, either PostgreSQL should enforce that empty folder restriction, or
> pg_basebackup should lift it and the documentation should reflect this.

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,

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-04-07 01:17:32 Re: Time to change pg_regress diffs to unified by default?
Previous Message Kyotaro HORIGUCHI 2017-04-07 01:05:55 Re: Logical Replication and Character encoding