Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tXqnU-00FGHh-FV for pgsql-hackers@arkaria.postgresql.org; Tue, 14 Jan 2025 23:58:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tXqnT-005F0X-3H for pgsql-hackers@arkaria.postgresql.org; Tue, 14 Jan 2025 23:58:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tXqnS-005F0O-Pr for pgsql-hackers@lists.postgresql.org; Tue, 14 Jan 2025 23:58:11 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tXqnR-000Rco-02 for pgsql-hackers@lists.postgresql.org; Tue, 14 Jan 2025 23:58:10 +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 50ENw1AZ1143417; Tue, 14 Jan 2025 18:58:01 -0500 From: Tom Lane To: Nathan Bossart cc: Fujii Masao , Andy Fan , pgsql-hackers@lists.postgresql.org Subject: Re: pgbench error: (setshell) of script 0; execution of meta-command failed In-reply-to: <724045.1736887918@sss.pgh.pa.us> References: <87ikqn5em7.fsf@163.com> <2422778.1736521065@sss.pgh.pa.us> <2425050.1736522451@sss.pgh.pa.us> <127979.1736622253@sss.pgh.pa.us> <570943.1736808714@sss.pgh.pa.us> <717458.1736884349@sss.pgh.pa.us> <724045.1736887918@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Tue, 14 Jan 2025 15:51:58 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1143415.1736899081.1@sss.pgh.pa.us> Date: Tue, 14 Jan 2025 18:58:01 -0500 Message-ID: <1143416.1736899081@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > OK, I'll make it so. Thanks for looking at it! Or not. My idea worked okay in v17, but not in older branches. Pre-v17, libpq itself can call pqsignal (though only in non- thread-safe builds). With this patch, that would have resulted in pulling src/port/pqsignal.o into libpq. libpq itself is fine with calling that version, but if a stub version of pqsignal() comes along for the ride then we have two candidates for which function will be exported. It would probably be possible to fix that, say by making the wrapper version be a separate .o module within libpgport. But it would be more work and complication, and I couldn't get excited about investing such effort for a hypothetical build problem. So I've pushed the patches as I originally proposed them. If anyone else is excited about doing something more, step right up. regards, tom lane