Horton

Thread

Commits

  1. Remove the option to build thread_test.c outside configure.

  1. Non-configure build of thread_test has been broken for awhile

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-10-18T17:20:12Z

    If you go into src/test/thread/ and type "make", you get
a bunch of "undefined reference to `pg_fprintf'" failures.
That's because thread_test.c #include's postgres.h but
the Makefile doesn't bother to link it with libpgport,
arguing (falsely) that that might not exist yet.

Presumably, this has been busted on all platforms since
96bf88d52, and for many years before that on platforms
that have always used src/port/snprintf.c.

Configure's use of the program works anyway because it doesn't
use the Makefile and thread_test.c doesn't #include postgres.h
when IN_CONFIGURE.

It doesn't really seem sane to me to support two different build
environments for thread_test, especially when one of them is so
little-used that it can be broken for years before we notice.
So I'd be inclined to rip out the Makefile and just consider
that thread_test.c is *only* meant to be used by configure.
If we wish to resurrect the standalone build method, we could
probably do so by adding LIBS to the Makefile's link command
... but what's the point, and what will keep it from getting
broken again later?

			regards, tom lane

  2. Re: Non-configure build of thread_test has been broken for awhile

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2020-10-19T21:41:43Z

    On 2020-Oct-18, Tom Lane wrote:

> It doesn't really seem sane to me to support two different build
> environments for thread_test, especially when one of them is so
> little-used that it can be broken for years before we notice.
> So I'd be inclined to rip out the Makefile and just consider
> that thread_test.c is *only* meant to be used by configure.
> If we wish to resurrect the standalone build method, we could
> probably do so by adding LIBS to the Makefile's link command
> ... but what's the point, and what will keep it from getting
> broken again later?

Standalone usage of that program is evidently non-existant, so +1 for
removing the Makefile and just keep the configure compile path for it.

BTW the only animal reporting without thread-safety in the buildfarm is
gaur.

  3. Re: Non-configure build of thread_test has been broken for awhile

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-10-20T16:25:48Z

    Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2020-Oct-18, Tom Lane wrote:
>> It doesn't really seem sane to me to support two different build
>> environments for thread_test, especially when one of them is so
>> little-used that it can be broken for years before we notice.
>> So I'd be inclined to rip out the Makefile and just consider
>> that thread_test.c is *only* meant to be used by configure.
>> If we wish to resurrect the standalone build method, we could
>> probably do so by adding LIBS to the Makefile's link command
>> ... but what's the point, and what will keep it from getting
>> broken again later?

> Standalone usage of that program is evidently non-existant, so +1 for
> removing the Makefile and just keep the configure compile path for it.

I concluded that if thread_test.c will only be used by configure,
then we should stick it under $(SRCDIR)/config/ and nuke the
src/test/thread/ subdirectory altogether.  See attached.

> BTW the only animal reporting without thread-safety in the buildfarm is
> gaur.

Yeah.  At some point maybe we should just drop support for non-thread-safe
platforms, but I'm not proposing to do that yet.

			regards, tom lane

  4. Re: Non-configure build of thread_test has been broken for awhile

    Bruce Momjian <bruce@momjian.us> — 2020-10-26T23:30:15Z

    On Tue, Oct 20, 2020 at 12:25:48PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > On 2020-Oct-18, Tom Lane wrote:
> >> It doesn't really seem sane to me to support two different build
> >> environments for thread_test, especially when one of them is so
> >> little-used that it can be broken for years before we notice.
> >> So I'd be inclined to rip out the Makefile and just consider
> >> that thread_test.c is *only* meant to be used by configure.
> >> If we wish to resurrect the standalone build method, we could
> >> probably do so by adding LIBS to the Makefile's link command
> >> ... but what's the point, and what will keep it from getting
> >> broken again later?
> 
> > Standalone usage of that program is evidently non-existant, so +1 for
> > removing the Makefile and just keep the configure compile path for it.
> 
> I concluded that if thread_test.c will only be used by configure,
> then we should stick it under $(SRCDIR)/config/ and nuke the
> src/test/thread/ subdirectory altogether.  See attached.

Sounds good.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee