From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
Cc: | Andy Fan <zhihuifan1213(at)163(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgbench error: (setshell) of script 0; execution of meta-command failed |
Date: | 2025-01-10 14:57:45 |
Message-ID: | 2422778.1736521065@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-01-10 14:58:37 | Re: pgbench error: (setshell) of script 0; execution of meta-command failed |
Previous Message | Michael Banck | 2025-01-10 14:56:31 | Re: Adding extension default version to \dx |