Re: ecpg PREPARE is not thread safe

Поиск
Список
Период
Сортировка
От Michael Meskes
Тема Re: ecpg PREPARE is not thread safe
Дата
Msg-id 20070921104518.GA25527@feivel.credativ.de
обсуждение исходный текст
Ответ на ecpg PREPARE is not thread safe  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Ответы Re: ecpg PREPARE is not thread safe  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Список pgsql-hackers
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!


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Heikki Linnakangas"
Дата:
Сообщение: Re: Improving the Performance of Full Table Updates
Следующее
От: Michael Meskes
Дата:
Сообщение: Re: compiler warnings in ecpglib/execute.c (uninitialized local variable 'prepname' used)