Re: file cloning in pg_upgrade and CREATE DATABASE

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: file cloning in pg_upgrade and CREATE DATABASE
Date: 2018-10-03 07:20:03
Message-ID: 20181003072003.GG2609@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 02, 2018 at 11:07:06PM -0300, Alvaro Herrera wrote:
> I see. Peter is proposing to have a fourth mode, essentially
> --transfer-mode=clone-or-copy.

Yes, a mode which depends on what the file system supports. Perhaps
"safe" or "fast" could be another name, in the shape of the fastest
method available which does not destroy the existing cluster's data.

> Thinking about a generic tool that wraps pg_upgrade (say, Debian's
> wrapper for it) this makes sense: just use the fastest non-destructive
> mode available. Which ones are available depends on what the underlying
> filesystem is, so it's not up to the tool's writer to decide which to
> use ahead of time.

This could have merit. Now, it seems to me that we have two separate
concepts here, which should be addressed separately:
1) cloning file mode, which is the new actual feature.
2) automatic mode, which is a subset of the copy mode and the new clone
mode. What I am not sure when it comes to that stuff is if we should
consider in some way the link mode as being part of this automatic
selection concept..
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2018-10-03 07:37:29 Re: pgsql: Improve autovacuum logging for aggressive and anti-wraparound ru
Previous Message Michael Paquier 2018-10-03 06:40:03 Re: [WIP PATCH] Index scan offset optimisation using visibility map