Horton

Re: Thread-unsafe coding in ecpg

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: "Joshua D. Drake" <jd@commandprompt.com>, Andres Freund <andres@anarazel.de>, "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>, Michael Meskes <meskes@postgresql.org>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2019-01-24T03:53:24Z
Lists: pgsql-hackers 
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,
> but apparently that's over-optimistic.

I pushed a patch to fix that.

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:

    while (1)
    {
        $fetch forward c into :i, :j, :c;
        if (sqlca.sqlcode == 100) break;
        else if (sqlca.sqlcode != 0) printf ("Error: %ld\n", sqlca.sqlcode);

        if (risnull(CDECIMALTYPE, (char *)&j))
            printf("%d NULL\n", i);
        else
        {
            int a;

            dectoint(&j, &a);
            printf("%d %d \"%s\"\n", i, a, c);
        }
    }


I know zip about ecpg coding practices, but wouldn't it be a better idea
to break out of the loop on seeing an error?

			regards, tom lane

Commits

  1. Remove _configthreadlocale() calls in ecpg test suite.

  2. Remove infinite-loop hazards in ecpg test suite.

  3. Blind attempt to fix _configthreadlocale() failures on MinGW.

  4. Avoid thread-safety problem in ecpglib.

  5. Second try at fixing ecpglib thread-safety problem.