I wrote: > Alvaro Herrera <alvhe...@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