From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Using base backup exclusion filters to reduce data transferred with pg_rewind |
Date: | 2018-03-25 23:59:35 |
Message-ID: | 20180325235935.GE24540@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Michael Paquier (michael(at)paquier(dot)xyz) wrote:
> On Sat, Mar 24, 2018 at 11:14:34PM -0400, Tom Lane wrote:
> > Stephen Frost <sfrost(at)snowman(dot)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.
While I agree that some consideration should be given to the impact a
change has on back-patching, I continue to be of the opinion that this
would be a good change, for the reasons which I outlined up-thread.
That said, I don't hold that position very strongly.
> 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.
Intrusive, at least from my viewpoint, is more about how the code is
changed around and/or refactored than about the impact it has on
back-patching. These are pretty mechanical changes, after all.
I'm not particularly thrilled with the idea of having two independent
lists of hard-coded paths to maintain, even with comments in both places
saying to update the other list.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2018-03-26 00:43:21 | Re: Undesirable entries in typedefs list |
Previous Message | Andrew Dunstan | 2018-03-25 23:57:49 | Buildfarm client release 7 |