Re: Using base backup exclusion filters to reduce data transferred with pg_rewind - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Using base backup exclusion filters to reduce data transferred with pg_rewind
Date
Msg-id 12387.1521947674@sss.pgh.pa.us
Whole thread Raw
In response to Re: Using base backup exclusion filters to reduce data transferredwith pg_rewind  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Using base backup exclusion filters to reduce data transferredwith pg_rewind
List pgsql-hackers
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.

Furthermore, I think it's completely silly to claim that this sort of
thing is a gain in readability or understandability:

-                path = psprintf("base/%u/t%d_%u",
-                                dbNode, backendId, relNode);
+                path = psprintf("%s/%u/t%d_%u",
+                                PG_BASE_DIR, dbNode, backendId, relNode);

For my money it's a loss on both points.  The extra level of indirection
is just obscuring what's actually happening and putting extra cognitive
load on the reader.

We have better things to spend our time on.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: JIT compiling with LLVM v12.2
Next
From: Tomas Vondra
Date:
Subject: Re: [PROPOSAL] Shared Ispell dictionaries