Re: Thread-unsafe coding in ecpg

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Michael Meskes <meskes(at)postgresql(dot)org>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Thread-unsafe coding in ecpg
Date: 2019-01-23 22:37:25
Message-ID: d06a16bc-52d6-9f0d-2379-21242d7dbe81@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 1/22/19 12:50 PM, Andrew Dunstan wrote:
> On 1/21/19 10:00 PM, Andrew Dunstan wrote:
>> On 1/21/19 3:25 PM, Tom Lane wrote:
>>> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>>>> On 1/21/19 12:05 PM, Tom Lane wrote:
>>>>> Is there a newer version of mingw that does have this functionality?
>>>> Apparently this can be done with thee 64bit version:
>>>> https://stackoverflow.com/questions/33647271/how-to-use-configthreadlocale-in-mingw
>>> Hmm, the followup question makes it sound like it still didn't work :-(.
>>>
>>> However, since the mingw build is autoconf-based, seems like we can
>>> install a configure check instead of guessing. Will make it so.
>>>
>>> Task for somebody else: run a MinGW64 buildfarm member.
>>>
>>>
>> I could set that up in just about two shakes of a lamb's tail - I have a
>> script to do so all tested on vagrant/aws within the last few months.
>>
>>
>> What I don't have is resources. My Windows resources are pretty much
>> tapped out. I would need either some modest hardware or a Windows VM
>> somewhere in the cloud - could be anywhere but I'm most at home on AWS.
>>
>
> Incidentally, jacana *is* running mingw64, but possibly not a young
> enough version. I just ran a test on an up to date version and it found
> the config setting happily, and passed the make stage.
>
>
> I can look at upgrading jacana to a more modern compiler. The version
> it's running is 4.9.1, apparently built around Oct 2014, so it's not
> that old.
>
>

I have just spent a large amount of time testing the committed fix with
a number of versions of gcc. It blows up on any compiler modern enough
to know about _configthreadlocale

Essentially what happens is this:

============== running regression test queries        ==============
test compat_informix/dec_test     ... ok
test compat_informix/charfuncs    ... ok
test compat_informix/rfmtdate     ... ok
test compat_informix/rfmtlong     ... ok
test compat_informix/rnull        ... stdout stderr FAILED
test compat_informix/sqlda        ... stdout stderr FAILED (test
process exited with exit code 1)
test compat_informix/describe     ... stdout stderr FAILED (test
process exited with exit code 1)
test compat_informix/test_informix ...

At this point the regression tests hang and the disk starts filling up
rapidly.

This has been tested with versions 5.4.0, 6.4.0, 7.3.0, 8.1.0 and 8.2.1.
The first 4 are downloaded direct from the Mingw64 repo, the last is
from Msys2's mingw64 toolchain.

I'm trying to find out more info, but what we have right now is pretty
broken.

Reverting commits ee27584c4a and 8eb4a9312 cures[*] the problem.

cheers

andrew

[*] FSVO "cure". I am still getting intermittent errors but no hangs.

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-01-23 23:01:35 Re: Thread-unsafe coding in ecpg
Previous Message Alexander Korotkov 2019-01-23 22:16:22 Re: jsonpath