RE: Reconnect a single connection used by multiple threads in embedded SQL in C application causes error.

Поиск
Список
Период
Сортировка
От egashira.yusuke@fujitsu.com
Тема RE: Reconnect a single connection used by multiple threads in embedded SQL in C application causes error.
Дата
Msg-id TYWPR01MB7202C109CDE4D7A60D048F9CFF059@TYWPR01MB7202.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Reconnect a single connection used by multiple threads in embedded SQL in C application causes error.  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Ответы Re: Reconnect a single connection used by multiple threads in embedded SQL in C application causes error.
Список pgsql-bugs
Hi Horiguchi-san,

Thank you for the comment.
I attached the revised patch.

> It looks like too verbose.  Couldn't it be summarized as something
> like this?
>
> > Current connection is managed in a per-thread manner. For the first
> > use on a thread, it is the most recently used one in the process.

Yes.
I thought that I needed a detailed explanation of the current connection for the note below, but this certainly seems
tobe summable. 


> This doesn't look like a API documentation but a procedual
> documentation.  IMO there's no particular reason that we should
> officially concretely suggest how mulitple connectinos are managed on
> somebody's application.  And part of the section is already in the
> documentation.
>
> |  <para>
> |   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.
> |  </para>
>
> So, it would boil down to the caution about disconnection.
>
> > Note that connections are shared among all threads.  Be careful not
> > to DISCONNECT a connection that is to be used in another thread.

I wanted to make a document that could avoid the use cases that I reported, so I tried to write a note according to the
occurrenceconditions. 
However, this was also too verbose, so I rewrote the note as you suggested.
And since there is no mention of the current connection, I changed the section to add it to "36.2.3. Closing a
Connection".

I think I might be better to add "In the worst case, this may cause an application crash." to this note so that users
canavoid the problem more strongly. 
However, this sentence can also be read as claiming that there is an implementation problem.
Should not I add this sentence?

I am also a little concerned that the revised text will be interpreted as prohibiting the following use cases:

> - One thread does all the CONNECT and DISCONNECT commands. Other threads just use the default connection, with mutual
exclusion.



Regards,
Yusuke Egashira

Вложения

В списке pgsql-bugs по дате отправления:

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #17425: Postgres service does not start if path to data folder ends with backslash.
Следующее
От: "hirose.masay-01@fujitsu.com"
Дата:
Сообщение: RE: BUG #17421: Core dump in ECPGdo() when calling PostgreSQL API from 32-bit client for RHEL8