RE: Is PREPARE of ecpglib thread safe? - Mailing list pgsql-hackers

From Matsumura, Ryo
Subject RE: Is PREPARE of ecpglib thread safe?
Date
Msg-id 03040DFF97E6E54E88D3BFEE5F5480F737AC4316@G01JPEXMBYT04
Whole thread Raw
In response to Re: Is PREPARE of ecpglib thread safe?  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses RE: Is PREPARE of ecpglib thread safe?
List pgsql-hackers
Horiguchi-san, Kuroda-san

> Horiguchi-san wrote:
> > 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.

I was wrong. I understand that DECLARE STATEMENT should be same policy as the combination of PREPARE STATEMENT and SET
CONNECTION.
We should fix the current implementation of DECLARE STATEMENT.

Current:
  t1:Thread1: exec sql at conn1 declare st1 statement;
  t2:Thread2: exec sql at conn2 declare st1 statement;  // NG

ToBe:
  t1:Thread1: exec sql at conn1 declare st1 statement;
  t2:Thread2: exec sql at conn2 declare st1 statement;  // OK
  t3:Thread2: exec sql prepared st1 from "select 1";    // OK: prepared on conn2
  t4:Thread1: exec sql execute st1;                     // NG: not prepared
  t5:Thread2: exec sql execute st1;                     // OK: executed on conn2

  t1:Thread1: exec sql at conn1 declare st1 statement;
  t2:Thread1: exec sql at conn2 declare st1 statement;  // NG

Regards
Ryo Matsumura



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: hyrax vs. RelationBuildPartitionDesc
Next
From: Haribabu Kommi
Date:
Subject: Re: current_logfiles not following group access and instead followslog_file_mode permissions