Hi, Alvaro and all,
> this patch hasn't been posted by the author so let's assume
> they're not authorizing them to use it.
Not sure what you mean. I am the author and I authorize anyone to do
whatever they want with it.
> Otherwise, why wouldn't they just post it here instead of doing the
absur
I wrote:
> After a bit more thought, HEAD+v14 is also my preference. I'm not
> eager to change this in stable branches, but it doesn't seem too
> late for v14.
Perusing the commit log, I realized that there's another reason why
v14 is a good cutoff: thread_test.c was in a different place with
an
Andres Freund writes:
> On 2021-07-23 17:18:37 -0400, Tom Lane wrote:
>> Should we back-patch this, or just do it in HEAD? Maybe HEAD+v14?
> I'm ok with all, with a preference for HEAD+v14, followed by HEAD, and
> all branches.
After a bit more thought, HEAD+v14 is also my preference. I'm not
Hi,
On 2021-07-23 17:18:37 -0400, Tom Lane wrote:
> I'm not prepared to go that far just yet; but certainly we can stop
> expending configure cycles on the case.
>
> Should we back-patch this, or just do it in HEAD? Maybe HEAD+v14?
I'm ok with all, with a preference for HEAD+v14, followed by HE
Andres Freund writes:
> On 2021-07-23 13:42:41 -0400, Tom Lane wrote:
>> TBH, I wonder why we don't just nuke thread_test.c altogether.
> +1. And before long it might be time to remove support for systems
> without threads...
I'm not prepared to go that far just yet; but certainly we can stop
ex
Hi,
On 2021-07-23 13:42:41 -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > ... that said, I wonder why would we do this in the thread_test program
> > rather than in configure itself. Wouldn't it make more sense for the
> > configure test to be skipped altogether (marking the result as
> > t
On Fri, Jul 23, 2021 at 01:42:41PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > ... that said, I wonder why would we do this in the thread_test program
> > rather than in configure itself. Wouldn't it make more sense for the
> > configure test to be skipped altogether (marking the result a
Alvaro Herrera writes:
> ... that said, I wonder why would we do this in the thread_test program
> rather than in configure itself. Wouldn't it make more sense for the
> configure test to be skipped altogether (marking the result as
> thread-safe) when running under thread sanitizer, if there's a
This is a reply to an old thread with the same name:
https://www.postgresql.org/message-id/1513971675.5870501.1439797066345.javamail.ya...@mail.yahoo.com
I was not able to do a proper reply since I cannot download the raw
message: https://postgrespro.com/list/thread-id/2483942
Anyway, the problem
On 2021-Jul-23, Alvaro Herrera wrote:
> On 2021-Jul-23, Mikhail Matrosov wrote:
>
> > I am not sure what is the proper fix for the issue, but I at least suggest
> > to disable this test when building with thread sanitizer:
> > https://github.com/conan-io/conan-center-index/pull/6472/files#diff-b8
On 2021-Jul-23, Mikhail Matrosov wrote:
> I am not sure what is the proper fix for the issue, but I at least suggest
> to disable this test when building with thread sanitizer:
> https://github.com/conan-io/conan-center-index/pull/6472/files#diff-b8639f81e30f36c8ba29a0878f1ef4d9f1552293bc9098ebb9b
11 matches
Mail list logo
