From: | "egashira(dot)yusuke(at)fujitsu(dot)com" <egashira(dot)yusuke(at)fujitsu(dot)com> |
---|---|
To: | 'Noah Misch' <noah(at)leadboat(dot)com> |
Cc: | "'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-02-22 12:06:23 |
Message-ID: | TYWPR01MB7202664D55ED1F8103B42FA7FF3B9@TYWPR01MB7202.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi Noah,
Thank you for replying.
> > 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.
> 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.
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."
----
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.
Regards,
Yusuke Egashira
From | Date | Subject | |
---|---|---|---|
Next Message | Martin Kos | 2022-02-22 13:17:06 | Bug in execution of EXISTS and IN clauses for large tables |
Previous Message | PG Bug reporting form | 2022-02-22 10:03:02 | BUG #17413: update of partitioned table via postgres_fdw updates to much rows |