Re: Is PREPARE of ecpglib thread safe?
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: Is PREPARE of ecpglib thread safe? |
Дата | |
Msg-id | 20190314.195553.10452486.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | RE: Is PREPARE of ecpglib thread safe? ("Matsumura, Ryo" <matsumura.ryo@jp.fujitsu.com>) |
Ответы |
RE: Is PREPARE of ecpglib thread safe?
|
Список | pgsql-hackers |
At Thu, 14 Mar 2019 09:49:11 +0000, "Matsumura, Ryo" <matsumura.ryo@jp.fujitsu.com> wrote in <03040DFF97E6E54E88D3BFEE5F5480F737AC3AD8@G01JPEXMBYT04> > Horiguchi-san > > Thank you for your comment. > > > 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. > > I understand it, but current scope of StatementCache and DeclareStatementList seems not > to be limitted within each connection, isn't it? Yes, so I wrote that "if it is done by a single mutex". Feel free to fix that if it is still problematic:) > Therefore, I thought the operation on them must be thread safe. I'm not against that. > For example, scope of DescriptorList in descriptor.c is within thread (not connection) > by using pthread_getspecific/ pthread_setspecific(). It seems like a local cache of server-side data, which is similar to catcache on server side for each process. I don't think prepared statements is in that category. A prepared statement is bonded to a connection, not to a thread. Different threads can execute the same prepared statement on the same connection. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: