Re: Using base backup exclusion filters to reduce data transferred with pg_rewind
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephen Frost <sfrost@snowman.net>, Fujii Masao <masao.fujii@gmail.com>, Anastasia Lubennikova <a.lubennikova@postgrespro.ru>, Michael Paquier <michael.paquier@gmail.com>, Postgres hackers <pgsql-hackers@postgresql.org>
Date: 2018-03-25T08:06:13Z
Lists: pgsql-hackers
On Sat, Mar 24, 2018 at 11:14:34PM -0400, Tom Lane wrote: > Stephen Frost <sfrost@snowman.net> writes: >> I don't completely buy off on the argument that having these #define's >> would make it easier for forks (we've had quite a few folks fork PG, but >> how many of them have actually changed "base"?) and I'm on the fence >> about if these will make our lives simpler down the road when it comes >> to changing the directory names > > I am distressed that nobody, apparently, is putting any weight on the > back-patching pain that will result from widespread replacement of path > names with macros. I don't buy that either we or anyone else will need > to change these names in future, so I see pain and effectively no > gain. That's actually something I worry about as well (as the author!), which is why I qualify the changes as intrusive. At the end, I think that I would be tempted to just do #3, aka to keep a copy of the filter list in pg_rewind code while hardcoding a minimum of names and mention in both basebackup.c and pg_rewind code to not forget to update the filter list if necessary. New paths in the data folder are not added on a monthly basis either, and not all of them can be filtered out so that's easy to maintain. -- Michael
Commits
-
Make pg_rewind skip files and directories that are removed during server start.
- 266b6acb312f 11.0 landed