On 5/15/19 3:38 AM, Tom Lane wrote:
I wrote:
I think moving fe_utils/logging.[hc] to
common/ is definitely the way to get out of this problem.
I've pushed that, so Ian's problem should be gone as of HEAD.
Thanks, that resolves the issue!
Regards
Ian Barwick
--
Ian Barwick
I wrote:
> I think moving fe_utils/logging.[hc] to
> common/ is definitely the way to get out of this problem.
I've pushed that, so Ian's problem should be gone as of HEAD.
regards, tom lane
Alvaro Herrera writes:
> On 2019-May-13, Tom Lane wrote:
>> 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 t
On 2019-May-13, Tom Lane wrote:
> 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 ei
I wrote:
> Alvaro Herrera 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,
Alvaro Herrera writes:
> On 2019-May-09, Tom Lane wrote:
>> I'm not especially on board with the idea of moving FE-specific error
>> handling code into libpgcommon, as that breaks the concept that
>> src/common/ is broadly for code that can work in either frontend or
>> backend contexts. However,
On 2019-May-09, Tom Lane wrote:
> I'm not especially on board with the idea of moving FE-specific error
> handling code into libpgcommon, as that breaks the concept that
> src/common/ is broadly for code that can work in either frontend or
> backend contexts. However, we already have a few violat
I wrote:
> Ian Barwick writes:
>> Commit cc8d4151 [*] introduced a dependency between some functions in
>> libpgcommon and libpgfeutils,
> This seems rather seriously broken. I do not think the answer is to
> create a global dependency on libpgfeutils.
Or, to be clearer: fe_utils has had depend
On Tue, May 07, 2019 at 09:46:07AM -0400, Tom Lane wrote:
Ian Barwick writes:
Commit cc8d4151 [*] introduced a dependency between some functions in
libpgcommon and libpgfeutils,
This seems rather seriously broken. I do not think the answer is to
create a global dependency on libpgfeutils.
Ian Barwick writes:
> Commit cc8d4151 [*] introduced a dependency between some functions in
> libpgcommon and libpgfeutils,
This seems rather seriously broken. I do not think the answer is to
create a global dependency on libpgfeutils.
regards, tom lane
Hi
Commit cc8d4151 [*] introduced a dependency between some functions in
libpgcommon and libpgfeutils, which is not reflected in the linker options
provided when building an external program using PGXS, e.g. attempting to
build the attached (trivial) example results in:
$ PATH=$PG_HEAD:$PATH
11 matches
Mail list logo
