Re: [HACKERS] ecpg PREPARE is not thread safe

2007-09-21 Thread Michael Meskes 
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: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] ecpg PREPARE is not thread safe

2007-09-21 Thread ITAGAKI Takahiro 

Michael Meskes [EMAIL PROTECTED] 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



---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match