From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | matsumura(dot)ryo(at)jp(dot)fujitsu(dot)com |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Is PREPARE of ecpglib thread safe? |
Date: | 2019-03-14 08:05:24 |
Message-ID: | 20190314.170524.106780821.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello.
At Thu, 14 Mar 2019 07:17:08 +0000, "Matsumura, Ryo" <matsumura(dot)ryo(at)jp(dot)fujitsu(dot)com> wrote in <03040DFF97E6E54E88D3BFEE5F5480F737AC390D(at)G01JPEXMBYT04>
> Hi
>
> I'm afraid that PREPARE of ecpglib is not thread safe.
> The following global variables are modified without any locking system.
> Is it unnecessary worry?
>
> [interfaces/ecpg/ecpglib/prepare.c]
> static int nextStmtID = 1;
> static stmtCacheEntry *stmtCacheEntries = NULL;
> static struct declared_statement *g_declared_list;
A connection cannot be concurrently used by multiple threads so
the programmer must guard connections using mutex [1] or
friends. If it is done by a single mutex (I suppose it is
common.), there's no race condition also on the prepared
statement storage. I'm not sure it is explicitly aimed but I
suppose that there's no problem in a common usage of the library.
[1] https://www.postgresql.org/docs/current/ecpg-connect.html
> If your application uses multiple threads of execution, they
> cannot share a connection concurrently. You must either
> explicitly control access to the connection (using mutexes) or
> use a connection for each thread.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Mitar | 2019-03-14 08:05:59 | Re: Re: Feature: triggers on materialized views |
Previous Message | Evgeniy Efimkin | 2019-03-14 07:56:25 | Re: Special role for subscriptions |