Re: Duplicate usage of tablespace location?

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Duplicate usage of tablespace location?
Date: 2017-04-07 01:02:36
Message-ID: 20170407.100236.244222818.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I don't mean that this is the only or best way to go.

I apologize for the possible lack of explanation.

At Thu, 06 Apr 2017 12:03:51 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <21084(dot)1491494631(at)sss(dot)pgh(dot)pa(dot)us>
> Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> > I noticed by the following report, PostgreSQL can share the same
> > directory as tablespaces of two servers with different
> > pg-versions.
>
> > https://www.postgresql.org/message-id/2008148.rxBNyNRHPZ@peanuts2
>
> > 8.4 checked that the tablespace location is empty, but from 9.0,
> > the check is replaced with creating a PG_PGVER_CATVER
> > subdirectory. This works for multiple servers with the same
> > version, but don't for servers with different versions.
>
> Please explain why you think it doesn't work. This patch seems to
> be reverting an intentional behavioral change, and you haven't

I understand that the change is for in-place upgrade, not for
sharing a tablespace diretory between two version of PostgreSQL
servers. It actually rejects the second server with the same
version to come. If this is correct, it doesn't seem right to
accept the second server of the different version.

If we allow sharing of the directory, theoretically we can allow
the same between the same version of servers by adding system
identifier in the subdirectory name.

> really explained why we'd want to. It certainly doesn't look like
> it addresses the referenced complaint about pg_basebackup behavior.

My point is that "the direcotry for newly created tablespace is
really reuiqred to be literary empty or not?"

Practically it doesn't need to be empty and succesful creation of
PG_VER_CATVER directory is enough as the current implement
does. If we take this way the documentation and pg_basebackup
should be changed and the problem will be resolved as the result.

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. All objects subsequently
- created within the tablespace will be stored in files underneath
- this directory.
+ CREATE TABLESPACE creates a subdirectory named after server
+ version in the location. The location must not contain a file
+ or directory of that name for the subdirectory. All objects
+ subsequently created within the tablespace will be stored in
+ files underneath the subdirectory.

Then, modify pg_basebackup to follow the description above.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2017-04-07 01:05:55 Re: Logical Replication and Character encoding
Previous Message Amit Langote 2017-04-07 00:53:30 Re: Remove pg_stat_progress_vacuum from Table 28.2