Re: Is PREPARE of ecpglib thread safe?
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: Is PREPARE of ecpglib thread safe? |
Дата | |
Msg-id | 20190315.153350.226491548.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?
(Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
RE: Is PREPARE of ecpglib thread safe? ("Matsumura, Ryo" <matsumura.ryo@jp.fujitsu.com>) |
Список | pgsql-hackers |
At Fri, 15 Mar 2019 05:27:01 +0000, "Matsumura, Ryo" <matsumura.ryo@jp.fujitsu.com> wrote in <03040DFF97E6E54E88D3BFEE5F5480F737AC3F24@G01JPEXMBYT04> > Hi Horiguchi-san, Kuroda-san > > Horiguchi-san, thank you for your comment. > > I have a question. > A bug of StatementCache is occurred in previous versions. > Should a patch be separated? > > > Horiguchi-san wrote: > > It seems like a local cache of server-side data, which is similar > > to catcache on server side for each process. > > I agree. > I will fix it with using pthread_setspecific like descriptor.c. > > > 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. > > A namespace of declared statement is not connection independent. > Therefore, we must manage the namespce in global and consider about race condition. Right, and but thread independent. > For example, ecpglib must refer the information of (A) when ecpglib executes (B) > in order to occur "double declare" error. > > (A) exec sql at conn1 declare st1 statement; > (B) exec sql at conn2 declare st1 statement; On an interactive SQL environment like psql, we can declar pareared statements with the same name on different connections. Do you mean you are going to implement different way on ECPG? Actually the current ECPGprepare seems already managing prepared statements separately for each connections. This is naturally guarded by per-connection concurrencly control that applications should do. > this = ecpg_find_prepared_statement(name, con, &prev); What you showed at the beginning of this thread was the sutff for auto prepare, the name of which is generated using the global variable nextStmtID and stored into global stmtCacheEntries. They are not guarded at all and seem to need multithread-protection. > // If ecpglib didn't reject the above, ecpglib cannot judge > // which connection the followings should be executed on. > exec sql prepare st1 from "select 1"; > exec sql execute st1; I'm not sure about ECPG, but according to the documentation, the following statements should work correctly. SQL SET CONNECTION con1; EXEC SQL PREPARE st1 FROM "select 1"; EXEC SQL EXECUTE st1; should succeed and executed on con1. > Kuroda-san, is it right? > If it's right, I will fix it with using pthread_lock. Mmm. Are you saying that prepared statements on ECPG should have names in global namespace and EXECUTE should implicitly choose the underlying connection automatically from the name of a prepared statement? I don't think it is the right direction. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: