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

From: "egashira(dot)yusuke(at)fujitsu(dot)com" <egashira(dot)yusuke(at)fujitsu(dot)com>
To: 'Kyotaro Horiguchi' <horikyota(dot)ntt(at)gmail(dot)com>
Cc: "noah(at)leadboat(dot)com" <noah(at)leadboat(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: RE: Reconnect a single connection used by multiple threads in embedded SQL in C application causes error.
Date: 2022-03-04 11:49:39
Message-ID: TYWPR01MB7202C109CDE4D7A60D048F9CFF059@TYWPR01MB7202.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 to be 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 occurrence conditions.
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 can avoid 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

Attachment Content-Type Size
v2-add-multithreaded-note-to-ecpg-connection-document.patch application/octet-stream 1.9 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message hirose.masay-01@fujitsu.com 2022-03-05 06:45:21 RE: BUG #17421: Core dump in ECPGdo() when calling PostgreSQL API from 32-bit client for RHEL8
Previous Message PG Bug reporting form 2022-03-04 10:14:30 BUG #17425: Postgres service does not start if path to data folder ends with backslash.