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

From Kyotaro HORIGUCHI
Subject Re: Is PREPARE of ecpglib thread safe?
Date
Msg-id 20190314.170524.106780821.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Is PREPARE of ecpglib thread safe?  ("Matsumura, Ryo" <matsumura.ryo@jp.fujitsu.com>)
Responses RE: Is PREPARE of ecpglib thread safe?
List pgsql-hackers
Hello.

At Thu, 14 Mar 2019 07:17:08 +0000, "Matsumura, Ryo" <matsumura.ryo@jp.fujitsu.com> wrote in
<03040DFF97E6E54E88D3BFEE5F5480F737AC390D@G01JPEXMBYT04>
> Hi
> 
> I'm afraid that PREPARE of ecpglib is not thread safe.
> The following global variables are modified without any locking system.
> Is it unnecessary worry?
> 
>   [interfaces/ecpg/ecpglib/prepare.c]
>   static int  nextStmtID = 1;
>   static stmtCacheEntry *stmtCacheEntries = NULL;
>   static struct declared_statement *g_declared_list;

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.


[1] https://www.postgresql.org/docs/current/ecpg-connect.html

> If your application uses multiple threads of execution, they
> cannot share a connection concurrently. You must either
> explicitly control access to the connection (using mutexes) or
> use a connection for each thread.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Evgeniy Efimkin
Date:
Subject: Re: Special role for subscriptions
Next
From: Mitar
Date:
Subject: Re: Re: Feature: triggers on materialized views