> I like having a hard limit on the number of loop iterations;
> that should ensure that the test terminates no matter how confused
> ecpglib is.
I get your point and thus will only clean up the tests a little bit.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De
Michael Meskes writes:
> I wonder if it would be better to make the test cases use the proper
> whenever command instead. That would give us a slightly better
> functionality testing I'd say.
I like having a hard limit on the number of loop iterations;
that should ensure that the test terminates
> It looks to me like the reason that the ecpg tests went into an
> infinite
> loop is that compat_informix/test_informix.pgc has not considered the
> possibility of repeated statement failures:
> ...
Correct, this was missing a safeguard.
> I know zip about ecpg coding practices, but wouldn't i
On 1/23/19 10:53 PM, Tom Lane wrote:
> I wrote:
>> This suggests that, rather than throwing up our hands if the initial
>> _configthreadlocale call returns -1, we should act as though the function
>> doesn't exist, and just soldier on the same as before. The code in there
>> assumes that -1 is a
Oh, I just noticed something else: several of the ecpg test programs
contain
#ifdef WIN32
#ifdef _MSC_VER/* requires MSVC */
_configthreadlocale(_ENABLE_PER_THREAD_LOCALE);
#endif
#endif
Surely this is a kluge that we could now remove? We've protected the
only setlocale c
I wrote:
> This suggests that, rather than throwing up our hands if the initial
> _configthreadlocale call returns -1, we should act as though the function
> doesn't exist, and just soldier on the same as before. The code in there
> assumes that -1 is a can't-happen case and doesn't try to recover
Andrew Dunstan writes:
> On 1/23/19 6:01 PM, Tom Lane wrote:
>> Perhaps there's some sort of setup that MinGW's version needs that
>> we're not doing?
> This seems to suggest something worse: https://reviews.llvm.org/D40181
> Not sure I fully understand what's happening here, though.
Me either,
On 1/23/19 6:01 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> 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
> Bleah. Since the regular Windows buildfarm mem
Andrew Dunstan writes:
> 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
Bleah. Since the regular Windows buildfarm members seem happy, this
evidently means that M
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" 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 c
On January 22, 2019 9:50:19 AM PST, 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" writes:
On 1/21/19 12:05 PM, Tom Lane wrote:
> Is there a newer version of mingw that does have this
>functionality?
>>
On 1/21/19 10:00 PM, Andrew Dunstan wrote:
> On 1/21/19 3:25 PM, Tom Lane wrote:
>> "Joshua D. Drake" 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://st
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> BTW, I found another spot in descriptor.c where ecpglib is using
> setlocale() for the same purpose. Perhaps that one's not reachable
> in threaded apps, but I didn't see any obvious reason to think so,
> so I changed it too.
Ouch, thanks. And I'm sor
On 1/21/19 3:25 PM, Tom Lane wrote:
> "Joshua D. Drake" 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-conf
Andres Freund writes:
> We could just refuse to support thread safety on mingw if that's not
> supported? Or is that too aggressive?
Nah, we already had that discussion upthread. Given the lack of
prior complaints, we shouldn't break cases that are working today.
For instance, as long as setloc
"Joshua D. Drake" 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
Hi,
On 2019-01-21 15:05:23 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Seems jacana might not have like this change?
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2019-01-21%2019%3A01%3A28
>
> Hmm. So mingw doesn't provide access to _configthreadlocale().
> That's
On 1/21/19 12:05 PM, Tom Lane wrote:
Andres Freund writes:
Seems jacana might not have like this change?
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2019-01-21%2019%3A01%3A28
Hmm. So mingw doesn't provide access to _configthreadlocale().
That's unfortunate, at least if w
Andres Freund writes:
> Seems jacana might not have like this change?
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2019-01-21%2019%3A01%3A28
Hmm. So mingw doesn't provide access to _configthreadlocale().
That's unfortunate, at least if we think that mingw is still a viable
On 2019-01-21 12:09:30 -0500, Tom Lane wrote:
> "Tsunakawa, Takayuki" writes:
> > From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> >> So like this ...
>
> > How quick! Thank you. I've reviewed the code for both Unix and Windows,
> > and it looks OK. I haven't built the patch, but expect the build
> Thanks for reviewing! I've pushed this now (to HEAD only for the
> moment),
> we'll see what the buildfarm thinks.
>
> BTW, I found another spot in descriptor.c where ecpglib is using
> setlocale() for the same purpose. Perhaps that one's not reachable
> in threaded apps, but I didn't see any
"Tsunakawa, Takayuki" writes:
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> So like this ...
> How quick! Thank you. I've reviewed the code for both Unix and Windows, and
> it looks OK. I haven't built the patch, but expect the buildfarm to do the
> test.
Thanks for reviewing! I've pushe
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Hm. Well, I suppose we can figure that the buildfarm should tell us if
> there's anything too old that we still care about.
>
> So like this ...
How quick! Thank you. I've reviewed the code for both Unix and Windows, and
it looks OK. I haven't bui
"Tsunakawa, Takayuki" writes:
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> How far back does that exist?
> I couldn't find the relevant doc, but I've just confirmed I can use it with
> Visual Studio 2008 on Win7, which is my oldest combination at hand. VS 2008
> is already past its EOL, and
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> "Tsunakawa, Takayuki" writes:
> > On Windows, _configthreadlocale() enables us to restrict the effect of
> setlocale() only to the calling thread. We can call it in
> ecpg_do_prolog/epilog().
>
> How far back does that exist?
I couldn't find the rele
"Tsunakawa, Takayuki" writes:
> On Windows, _configthreadlocale() enables us to restrict the effect of
> setlocale() only to the calling thread. We can call it in
> ecpg_do_prolog/epilog().
How far back does that exist?
regards, tom lane
On Windows, _configthreadlocale() enables us to restrict the effect of
setlocale() only to the calling thread. We can call it in
ecpg_do_prolog/epilog().
https://docs.microsoft.com/en-us/cpp/parallel/multithreading-and-locales?view=vs-2017
Regards
Takayuki Tsunakawa
I wrote:
> On the third hand, the lack of previous reports suggests that maybe
> this whole thing is seldom a problem in practice. Maybe we should
> just use uselocale() where available and otherwise hope it's OK
> to keep on doing what we were doing.
If we go with that approach, I think we need
Michael Meskes writes:
>> No, we shouldn't use setlocale(), because it clearly is hazardous
>> even on platforms where it doesn't fail outright. I don't see
>> anything so wrong with just documenting the hazard. The situation
> Actually I meant using setlocale() and documenting that it must not
> > The question is, what do we do on those platforms? Use setlocale()
> > or
> > fallback to (a) and document that ecpg has to run in a C locale?
>
> No, we shouldn't use setlocale(), because it clearly is hazardous
> even on platforms where it doesn't fail outright. I don't see
> anything so wr
Andrew Gierth writes:
> Would it help if we had non-locale-aware functions for both
> floating-point output _and_ input? i.e. import a known-working strtod()
> (allowing us to remove all the hacks that have grown up around it, for
> special-case input and wonky error handling) with locale function
> "Michael" == Michael Meskes writes:
>> Therefore, it's plain crazy for ecpg to be calling setlocale()
>> inside threaded code. It looks to me like what ecpg is doing is
>> trying to defend itself against non-C LC_NUMERIC settings, which is
>> laudable, but this implementation of that is
Michael Meskes writes:
>> While (b) has more theoretical purity, I'm inclined to think it
>> doesn't really improve anybody's life compared to (a), because
>> --disable-thread-safety doesn't actually stop anyone from using
>> libpq or ecpglib in threaded environments. It just makes it
>> more lik
> While (b) has more theoretical purity, I'm inclined to think it
> doesn't really improve anybody's life compared to (a), because
> --disable-thread-safety doesn't actually stop anyone from using
> libpq or ecpglib in threaded environments. It just makes it
> more likely to fail when they do.
Th
Michael Meskes writes:
>> IOW, not only is setlocale() not necessarily thread-safe itself,
>> but using it to change locales in a multithread program is seriously
>> unsafe because of concurrent effects on other threads.
> Agreed.
> How about attached patch? According to my manpages it should on
> So my conclusion is that this version of setlocale() has some
> thread-safety issues. I was all set to go file a bug report
> when I noticed this in the POSIX spec for setlocale:
>
> The setlocale() function need not be thread-safe.
>
> as well as this:
>
> The global locale estab
I've found that a couple of different OpenBSD 6.4 machines fall over
badly in the ecpg regression tests, with output like
test sql/parser ... ok
test thread/thread... stdout stderr FAILED (test process was
terminated by signal 6: Abort trap)
test thread/thread_im
37 matches
Mail list logo
