Re: pgbench error: (setshell) of script 0; execution of meta-command failed
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Andy Fan <zhihuifan1213@163.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-01-10T14:57:45Z
Lists: pgsql-hackers
Fujii Masao <masao.fujii@oss.nttdata.com> writes: > Before this commit, pgbench used pqsignal() from port/pqsignal.c > to set the signal handler for SIGALRM. This version of pqsignal() > sets SA_RESTART for frontend code, so fgets() in runShellCommand() > wouldn't return NULL even if SIGALRM arrived during fgets(), > preventing the reported error. > On the other hand, currently, pgbench seems to use pqsignal() > from legacy-pqsignal.c, which doesn't set SA_RESTART for SIGALRM. > As a result, SIGALRM can interrupt fgets() in runShellCommand() > and make it return NULL, leading to the reported error. Oh, interesting. > I'm not sure if this change was an intentional result of that commit... Definitely not. I think we'd better look into how to undo that effect. Since legacy-pqsignal is really not supposed to be used by clients anymore, maybe we could just adjust it to set SA_RESTART for SIGALRM? The other alternatives I can think of amount to re-introducing link order dependencies, which would be horrid. regards, tom lane
Commits
-
Avoid symbol collisions between pqsignal.c and legacy-pqsignal.c.
- cfd7aadebea1 13.19 landed
- b935691b8b2f 16.7 landed
- a3b709cf73e0 15.11 landed
- a0dfeae0dc9a 17.3 landed
- 9a45a89c38f3 18.0 landed
- 02e69313ad0c 14.16 landed
-
Suppress macOS warnings about duplicate libraries in link commands.
- 06843df4abc5 17.0 cited