Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nzLXX-0001lF-9f for pgsql-bugs@arkaria.postgresql.org; Thu, 09 Jun 2022 17:01:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nzLXU-0000tt-L6 for pgsql-bugs@arkaria.postgresql.org; Thu, 09 Jun 2022 17:01:44 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nzLXU-0000th-CS for pgsql-bugs@lists.postgresql.org; Thu, 09 Jun 2022 17:01:44 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nzLXR-0003ke-2m for pgsql-bugs@lists.postgresql.org; Thu, 09 Jun 2022 17:01:44 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 259H1aha2060084; Thu, 9 Jun 2022 13:01:36 -0400 From: Tom Lane To: okano.naoki@jp.fujitsu.com cc: pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17514: Application with embedded SQL crashes when executing EXEC SQL PREPARE In-reply-to: <17514-edd4fad547c5692c@postgresql.org> References: <17514-edd4fad547c5692c@postgresql.org> Comments: In-reply-to PG Bug reporting form message dated "Thu, 09 Jun 2022 06:40:28 -0000" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <2059805.1654794010.0@sss.pgh.pa.us> Date: Thu, 09 Jun 2022 13:01:36 -0400 Message-ID: <2060083.1654794096@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2059805.1654794010.1@sss.pgh.pa.us> PG Bug reporting form writes: > Application with embedded SQL crashes with segmentation fault if I execute > EXEC SQL PREPARE > command before executing EXEC SQL CONNECT command (*1). > I know that it is the correct operation to execute EXEC SQL CONNECT command > first > and then execute EXEC SQL PREPARE command. > But I expect this wrong operation to result in an error, not a crash. We could do something like the attached, perhaps. Having said that, an application that includes no error checks is pretty unlikely to fail gracefully :-(. regards, tom lane ------- =_aaaaaaaaaa0 Content-Type: text/x-diff; name="ensure-TSD-key-is-valid-before-use.patch"; charset="us-ascii" Content-ID: <2059805.1654794010.2@sss.pgh.pa.us> Content-Description: ensure-TSD-key-is-valid-before-use.patch Content-Transfer-Encoding: quoted-printable diff --git a/src/interfaces/ecpg/ecpglib/connect.c b/src/interfaces/ecpg/e= cpglib/connect.c index 8dfcabe3b5..90f2ba9701 100644 --- a/src/interfaces/ecpg/ecpglib/connect.c +++ b/src/interfaces/ecpg/ecpglib/connect.c @@ -40,6 +40,8 @@ ecpg_get_connection_nr(const char *connection_name) if ((connection_name =3D=3D NULL) || (strcmp(connection_name, "CURRENT")= =3D=3D 0)) { #ifdef ENABLE_THREAD_SAFETY + ecpg_pthreads_init(); /* ensure actual_connection_key is valid */ + ret =3D pthread_getspecific(actual_connection_key); = /* @@ -78,6 +78,8 @@ ecpg_get_connection(const char *connection_name) if ((connection_name =3D=3D NULL) || (strcmp(connection_name, "CURRENT")= =3D=3D 0)) { #ifdef ENABLE_THREAD_SAFETY + ecpg_pthreads_init(); /* ensure actual_connection_key is valid */ + ret =3D pthread_getspecific(actual_connection_key); = /* ------- =_aaaaaaaaaa0--