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

I wrote:
> Actually, after re-reading the thread that led to 06843df4a [1],
> I think a better idea is to introduce some macro magic to force
> frontend clients to use libpgport's version of pqsignal() instead
> of the one from libpq. We mustn't change the real name of libpq's
> version, but I think we could get away with that for libpgport.

After studying this more, I think what we should do in HEAD is
even more aggressive: let's make the real name of port/pqsignal.c's
function be either pqsignal_fe in frontend, or pqsignal_be in backend.
This positively ensures that there's no collision with libpq's
export, and it seems like a good idea for the additional reason that
the frontend and backend versions are not really interchangeable.

However, we can't get away with that in released branches because
it'd be an ABI break for any outside code that calls pqsignal.
What I propose doing in the released branches is what's shown in
the attached patch for v17: rename port/pqsignal.c's function to
pqsignal_fe in frontend, but leave it as pqsignal in the backend.
Leaving it as pqsignal in the backend preserves ABI for extension
modules, at the cost that it's not entirely clear which pqsignal
an extension that's also linked with libpq will get. But that
hazard affects none of our code, and it existed already for any
third-party extensions that call pqsignal. In principle using
"pqsignal_fe" in frontend creates an ABI hazard for outside users of
libpgport.a. But I think it's not really a problem, because we don't
support that as a shared library. As long as people build with
headers and .a files from the same minor release, they'll be OK.

BTW, this decouples legacy-pqsignal.c from pqsignal.c enough
that we could now do what's contemplated in the comments from
3b00fdba9: simplify that version by making it return void,
or perhaps better just a true/false success report.
I've not touched that point here, though.

regards, tom lane