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-14 09:49:11 |
Message-ID: | 03040DFF97E6E54E88D3BFEE5F5480F737AC3AD8@G01JPEXMBYT04 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
Therefore, I thought the operation on them must be thread safe.
For example, scope of DescriptorList in descriptor.c is within thread (not connection)
by using pthread_getspecific/ pthread_setspecific().
Regards
Ryo Matsumura
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2019-03-14 10:06:01 | Re: Tid scan improvements |
Previous Message | David Rowley | 2019-03-14 09:46:00 | Re: Inadequate executor locking of indexes |