At Wed, 2 Mar 2022 12:43:34 +0000, "egashira.yusuke@fujitsu.com" <egashira.yusuke@fujitsu.com> wrote in
> --_002_TYWPR01MB72027307B41182F8A12524ADFF039TYWPR01MB7202jpnp_
> Content-Type: text/plain; charset="iso-2022-jp"
> Content-Transfer-Encoding: quoted-printable
>
> Hi Noah,=20
>
> > > Would you like to propose a patch?
> >=20
> > Sure. I will work on creating a document patch.
>
> I reconfirmed the conditions under which this issue occurred.
> Since this happens when the current connection is disconnected by another t=
> hread in a multiple threaded application,
> I added an information about "the current connection in a multiple threaded=
> application" to explain the limitations.
>
> I attached the patch to this mail.
> I reported a version of PostgreSQL 12, but this patch is based on the maste=
> r branch.
+ The most recently opened connection becomes the current connection.
+ If your application uses multiple threads, each thread has its own
+ current connection, and it is the most recently opened connection
+ in each thread. Threads that have not yet opened the current
+ connection treat the most recently opened connection in the
+ application as the current connection. The current connection is
+ used by default when an SQL statement is to be executed (see later
+ in this chapter).
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.
+ If you execute an SQL statement without connection name in a thread in
+ multiple thread application, a thread must not do
+ <command>DISCONNECT</command> command for a connection which is
+ used as the current connection in other threads. In particular,
+ you should follow one of the following two use cases. The first is that
+ one thread does all the <command>CONNECT</command> and
+ <command>DISCONNECT</command> commands. Other threads just use the
+ current connection, with mutual exclusion. The second is that each
+ thread does its own <command>CONNECT</command>, <command>DISCONNECT</command>,
+ and other commands. Each thread has its own current connection.
+ No sharing at all.
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.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center