Re: pgbench error: (setshell) of script 0; execution of meta-command failed - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pgbench error: (setshell) of script 0; execution of meta-command failed
Date
Msg-id 2422778.1736521065@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgbench error: (setshell) of script 0; execution of meta-command failed  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: pgbench error: (setshell) of script 0; execution of meta-command failed
List 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



pgsql-hackers by date:

Previous
From: Michael Banck
Date:
Subject: Re: Adding extension default version to \dx
Next
From: Tom Lane
Date:
Subject: Re: pgbench error: (setshell) of script 0; execution of meta-command failed