Обсуждение: ecpg PREPARE is not thread safe
Hi, I encountered segfaults in a multi-threaded ecpg application. It uses PREPARE statements concurrently in several threads. The cause seems to be the global variable 'prep_stmts' in ecpg/ecpglib/prepare.c . It is accessed without any locks. I'm trying to fix it, but there are some approaches to fix it. 1. Add a giant lock to protect prep_stmts. 2. Put prep_stmtsinto TSD (Thread Specific Data). 3. Put prep_stmts into connection specific data. I think the proper approach is 3, because server-side prepared statements are independent in each connection. For that matter, are there any problems in current codes? Prepared statements are managed with a single list in it. Even if we have some kinds of exclusive controls, current ecpg might not good at prepared statements when we use multiple connections in a signle thread or do multiple PREPARE in multiple threads. If so, 1 and 2 are not correct fixes. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
On Fri, Sep 21, 2007 at 11:05:47AM +0900, ITAGAKI Takahiro wrote: > PREPARE statements concurrently in several threads. The cause seems to > be the global variable 'prep_stmts' in ecpg/ecpglib/prepare.c . > It is accessed without any locks. And it is global, right. This has to be fixed, you're right. > I think the proper approach is 3, because server-side prepared statements > are independent in each connection. For that matter, are there any problems Right now the prepared statements are not considered connection specific. I'm not sure whether the standard says anything about this. But moving this data shoudln't be a major problem. > Even if we have some kinds of exclusive controls, current ecpg might not > good at prepared statements when we use multiple connections in a signle > thread or do multiple PREPARE in multiple threads. If so, 1 and 2 are not > correct fixes. Sorry, I don't get this. What exactly are you talking about here? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> wrote: > Right now the prepared statements are not considered connection > specific. I'm not sure whether the standard says anything about this. > But moving this data shoudln't be a major problem. > > > Even if we have some kinds of exclusive controls, current ecpg might not > > good at prepared statements when we use multiple connections in a signle > > thread or do multiple PREPARE in multiple threads. If so, 1 and 2 are not > > correct fixes. > > Sorry, I don't get this. What exactly are you talking about here? I'm worried that prepared statements are used in another connection. ECPG does not consider in which connection the statements is prepared. Are there any mix-up problem here? If no, the TSD approach is enough to fix the race condition. If yes, per-connection approach is needed. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center