RE: Reconnect a single connection used by multiple threads in embedded SQL in C application causes error. - Mailing list pgsql-bugs

Hi.

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

> On Fri, Mar 04, 2022 at 11:49:39AM +0000, egashira.yusuke@fujitsu.com wrote:
> > > 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.
>
> There's no behavior specific to "the first use on a thread", and "most
> recently used" is not a factor.  Avoid those phrases.  (In a thread that has
> never opened a connection, each command that retrieves the current connection
> will retrieve the non-thread-specific current connection.)
>
> > Yes.
> > I thought that I needed a detailed explanation of the current connection for the note below, but this certainly
seemsto be summable. 
>
> For this particular paragraph, I liked your v1's level of verbosity more than
> this compact version.

I have reinstated v1's explanation of this paragraph because the current connection is relevant to the subsequent note.


> > I wanted to make a document that could avoid the use cases that I reported, so I tried to write a note according to
theoccurrence 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
userscan 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?
>
> It's okay to admit implementation problems.  I might write "Behavior is
> undefined if the current thread is not the thread that opened the connection."
> Referring to undefined behavior is a customary way for API docs to imply that
> a crash is possible.  If one wanted to be even more precise, "Behavior is
> undefined if the connection is the thread-specific current connection of any
> other thread."  However, the more-precise wording is harder to understand.
> Also, being more precise now could limit our freedom to change behavior later.

The most important thing I want to explain in the documentation is that the current connection should not be closed
fromanother thread. 
So I just added that to the DISCONNECT Note.


> > --- a/doc/src/sgml/ecpg.sgml
> > +++ b/doc/src/sgml/ecpg.sgml
> > @@ -222,10 +222,15 @@ EXEC SQL CONNECT TO <replaceable>target</replaceable> <optional>AS <replaceable>
> >    <para>
> >     The <replaceable>connection-name</replaceable> is used to handle
> >     multiple connections in one program.  It can be omitted if a
> > -   program uses only one connection.  The most recently opened
> > -   connection becomes the current connection, which is used by default
> > -   when an SQL statement is to be executed (see later in this
> > -   chapter).
> > +   program uses only one connection.
> > +  </para>
> > +
> > +  <para>
> > +   The most recently opened connection becomes the current connection.
>
> This is true.  Disconnecting also changes the current connection, to another
> one of the open connections.  Please document that somewhere appropriate.

I have added that behavior to the "Closing a Connection" section.


> > @@ -276,8 +281,8 @@ EXEC SQL CONNECT TO :target USER :user USING :passwd;
> >
> >    <para>
> >     SQL statements in embedded SQL programs are by default executed on
> > -   the current connection, that is, the most recently opened one.  If
> > -   an application needs to manage multiple connections, then there are
> > +   the current connection, that is, the most recently opened one in each thread.
>
> Likewise, this is not accurate if a disconnect of the current connection
> happened after the most recent open.  You could simply delete this claim,
> which would avoid defining the current connection in two places.

As I explained the current connection in detail before this section, I think that there is no need to supplement the
definitionof the current connection. 
Therefore, I removed the second half of this statement.


Regards,
Yusuke Egashira