Re: Is PREPARE of ecpglib thread safe?

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: matsumura(dot)ryo(at)jp(dot)fujitsu(dot)com
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Is PREPARE of ecpglib thread safe?
Date: 2019-03-14 10:55:53
Message-ID: 20190314.195553.10452486.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Thu, 14 Mar 2019 09:49:11 +0000, "Matsumura, Ryo" <matsumura(dot)ryo(at)jp(dot)fujitsu(dot)com> wrote in <03040DFF97E6E54E88D3BFEE5F5480F737AC3AD8(at)G01JPEXMBYT04>
> Horiguchi-san
>
> Thank you for your comment.
>
> > A connection cannot be concurrently used by multiple threads so
> > the programmer must guard connections using mutex [1] or
> > friends. If it is done by a single mutex (I suppose it is
> > common.), there's no race condition also on the prepared
> > statement storage. I'm not sure it is explicitly aimed but I
> > suppose that there's no problem in a common usage of the library.
>
> I understand it, but current scope of StatementCache and DeclareStatementList seems not
> to be limitted within each connection, isn't it?

Yes, so I wrote that "if it is done by a single mutex". Feel free
to fix that if it is still problematic:)

> Therefore, I thought the operation on them must be thread safe.

I'm not against that.

> For example, scope of DescriptorList in descriptor.c is within thread (not connection)
> by using pthread_getspecific/ pthread_setspecific().

It seems like a local cache of server-side data, which is similar
to catcache on server side for each process. 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.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2019-03-14 11:00:25 Re: Making all nbtree entries unique by having heap TIDs participate in comparisons
Previous Message Edmund Horner 2019-03-14 10:37:48 Re: Tid scan improvements