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

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

In response to

Responses

Browse pgsql-hackers by date

  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