From: Noah Misch <noah@leadboat.com>
To: egashira.yusuke@fujitsu.com <egashira.yusuke@fujitsu.com>
Cc: 'pgsql-bugs@lists.postgresql.org' <pgsql-bugs@lists.postgresql.org>
Subject: Re: Reconnect a single connection used by multiple threads in embedded SQL in C application causes error.
Date: Tue, 22 Feb 2022 21:00:15 -0800
Message-ID: <20220223050015.GC3838703@rfd.leadboat.com> (raw)
In-Reply-To: <TYWPR01MB7202664D55ED1F8103B42FA7FF3B9@TYWPR01MB7202.jpnprd01.prod.outlook.com>
References: <TYWPR01MB7202E14319002430B83F7ABBFF3A9@TYWPR01MB7202.jpnprd01.prod.outlook.com>
<20220221212928.GB3799825@rfd.leadboat.com>
<TYWPR01MB7202664D55ED1F8103B42FA7FF3B9@TYWPR01MB7202.jpnprd01.prod.outlook.com>
On Tue, Feb 22, 2022 at 12:06:23PM +0000, egashira.yusuke@fujitsu.com wrote:
> > > And, is there limitation that we can't CONNECT or DISCONNECT the DEFAULT connection inside a thread in multithreaded application?
> >
> > For now, yes. This is a bug. The documentation you quoted is out of date
> > with respect to the code. That documentation comes from commit 8f61184
> > (2003-12). The behavior of connections shared across threads changed in
> > commit 757fb0e (2004-03). Since that change, there's a per-thread record of
> > the default connection, in addition to a global notion of the default
> > connection. I suspect a few use cases work well today:
> >
> > - One thread does all the CONNECT and DISCONNECT commands. Other threads just
> > use the default connection, with mutual exclusion.
> > - Each thread does its own CONNECT, DISCONNECT, and other commands. Each
> > thread has its own default connection. No sharing at all.
>
> The documentation from commit 8f61184 seems to have been updated by the commit 0f33ee0 (2017-06).
> However, there is still lacking of information about the DEFAULT connection on per-thread, I understood.
Yes.
> > Your example does the CONNECT to establish the default connection in one
> > thread, and it does the DISCONNECT of the default connection in another
> > thread. That's buggy today.
> >
> > Another behavior that may qualify as a bug: ECPGsetconn() updates only the
> > thread-specific connection, while ECPGconnect() updates both the
> > thread-specific and global connections.
>
> I also understood that my example is impossible by the implementation bugs.
>
> I think it would take some time to fix these bugs.
Yes. I suspect the hard part will be picking a specification that makes your
case work better without breaking other important cases that work today.
> If it takes long time to fix it, will this limitation(*) be added to the documentation?
>
> [*] Based on your explanation:
> "If we use the default connection inside a thread in multithreaded application,
> CONNECT and DISCONNECT commands are allowed only following cases.
> - One thread does all the CONNECT and DISCONNECT commands.
> Other threads just use the default connection, with mutual exclusion.
> - Each thread does its own CONNECT, DISCONNECT, and other commands.
> Each thread has its own default connection. No sharing at all."
Would you like to propose a patch?
> An additional report:
> I also ran my reproduction application built with rh-postgresql12 libraries (installed from Red Hat Software Collections),
> and it crashed instead of an error in step 5 in my first email.
>
> * Actually, the error message in my first email came from postgresql built by myself (./configure --prefix=xxx).
>
> The backtrace is following.
> (gdb) bt
> #0 0x00007fa11a4ddd0f in ecpg_find_prepared_statement () from /opt/rh/rh-postgresql12/root/usr//lib64/libecpg.so.rh-postgresql12-6
> #1 0x00007fa11a4de11b in ecpg_prepared () from /opt/rh/rh-postgresql12/root/usr//lib64/libecpg.so.rh-postgresql12-6
> #2 0x00007fa11a4d8b65 in ecpg_do_prologue () from /opt/rh/rh-postgresql12/root/usr//lib64/libecpg.so.rh-postgresql12-6
> #3 0x00007fa11a4d8c33 in ecpg_do () from /opt/rh/rh-postgresql12/root/usr//lib64/libecpg.so.rh-postgresql12-6
> #4 0x00007fa11a4d8d5b in ECPGdo () from /opt/rh/rh-postgresql12/root/usr//lib64/libecpg.so.rh-postgresql12-6
> #5 0x0000000000401143 in thread_main2 ()
> #6 0x00007fa11a2bdea5 in start_thread () from /lib64/libpthread.so.0
> #7 0x00007fa119fe68cd in clone () from /lib64/libc.so.6
>
> I think this happened because the PGconn referenced by Thread#1 was destroyed in step 4 and then overwritten with invalid data.
That makes sense.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: noah@leadboat.com, egashira.yusuke@fujitsu.com, pgsql-bugs@lists.postgresql.org
Subject: Re: Reconnect a single connection used by multiple threads in embedded SQL in C application causes error.
In-Reply-To: <20220223050015.GC3838703@rfd.leadboat.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox