Horton

Re: allow_in_place_tablespaces vs. pg_basebackup

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Thomas Munro <thomas.munro@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers@postgresql.org
Date: 2023-04-14T20:11:47Z
Lists: pgsql-hackers 
On Tue, Mar 28, 2023 at 9:40 PM Michael Paquier <michael@paquier.xyz> wrote:
> Looking at the patch, nothing really stands out..

It doesn't seem like anyone's unhappy about this patch. I don't think
it's necessary to back-patch it, given that in-place tablespaces are
intended for developer use, not real-world use, and also given that
the patch requires changing both a bit of server-side behavior and
some client-side behavior and it seems unfriendly to create behavior
skew of that sort in minor release. However, I would like to get it
committed to master.

Do people think it's OK to do that now, or should I wait until we've
branched? I personally think this is bug-fix-ish enough that now is
OK, but I'll certainly forebear if others disagree.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Commits

  1. Fix pg_basebackup with in-place tablespaces some more.

  2. Fix pg_basebackup with in-place tablespaces.

  3. Allow "in place" tablespaces.

  4. Avoid including tablespaces inside PGDATA twice in base backups

  5. Tablespaces. Alternate database locations are dead, long live tablespaces.