From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Non-configure build of thread_test has been broken for awhile |
Date: | 2020-10-20 16:25:48 |
Message-ID: | 649996.1603211148@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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
Attachment | Content-Type | Size |
---|---|---|
remove-standalone-thread-testing.patch | text/x-diff | 10.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2020-10-20 17:53:04 | Re: [PATCH] SET search_path += octopus |
Previous Message | David Steele | 2020-10-20 15:13:34 | Re: PostgresNode::backup uses spread checkpoint? |