I wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> I wonder if a better solution isn't to move the file_utils stuff to
>> fe_utils. Half of it is frontend-specific. The only one that should be
>> shared to backend seems to be fsync_fname ... but instead of sharing it,
>> we have a second copy in fd.c.
> Hm, if file_utils is the only thing in common/ that uses this, and we
> expect that to remain true, that would fix the issue. But ...
Thumbing through commit cc8d41511, I see that it already touched
five common/ modules
diff --git a/src/common/controldata_utils.c b/src/common/controldata_utils.c
diff --git a/src/common/file_utils.c b/src/common/file_utils.c
diff --git a/src/common/pgfnames.c b/src/common/pgfnames.c
diff --git a/src/common/restricted_token.c b/src/common/restricted_token.c
diff --git a/src/common/rmtree.c b/src/common/rmtree.c
Several of those have substantial backend components, so moving them
to fe_utils is a nonstarter. I think moving fe_utils/logging.[hc] to
common/ is definitely the way to get out of this problem.
I started working on a patch to do that, and soon noticed that there
are pre-existing files logging.[hc] in src/bin/pg_rewind/. This seems
like a Bad Thing, in fact the #includes in pg_rewind/ are already a
little confused due to this. I think we should either rename those
two pg_rewind files to something else, or rename the generic ones,
perhaps to "fe_logging.[hc]". The latter could be done nearly
trivially as part of the movement patch, but on cosmetic grounds
I'd be more inclined to do the former instead. Thoughts?
regards, tom lane