RE: Is PREPARE of ecpglib thread safe?

From: "Matsumura, Ryo" <matsumura(dot)ryo(at)jp(dot)fujitsu(dot)com>
To: 'Kyotaro HORIGUCHI' <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: Is PREPARE of ecpglib thread safe?
Date: 2019-03-15 05:27:01
Message-ID: 03040DFF97E6E54E88D3BFEE5F5480F737AC3F24@G01JPEXMBYT04
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.
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;

// 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;

Kuroda-san, is it right?
If it's right, I will fix it with using pthread_lock.

Regards
Ryo Matsumura

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Imai, Yoshikazu 2019-03-15 05:40:26 RE: speeding up planning with partitions
Previous Message Kyotaro HORIGUCHI 2019-03-15 05:24:29 Re: Fix typo in test code comments