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

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Andy Fan <zhihuifan1213(at)163(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pgbench error: (setshell) of script 0; execution of meta-command failed
Date: 2025-01-14 20:49:27
Message-ID: Z4bN1z_Ce_lxldj4@nathan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 14, 2025 at 02:52:29PM -0500, Tom Lane wrote:
> After more thought I've realized that the asymmetrical detection
> here isn't all that bad, because the outcomes are different.
> If we fail to catch old-headers-and-new-library, the result will
> either be a link failure or (if the extension uses libpq) silently
> linking to libpq's pqsignal, which was likely not what was intended.
> If we fail to catch the other case, the result is always a link
> failure, and that will happen at build time not in the field.

Assuming libpgport is only used as a static library, I think that makes
sense. My web searches indicate that it is possible to do things like
convert a static library to a dynamic one, but perhaps that's far enough
beyond the realm of things we care about.

> So now I'm inclined to include the ABI-compatible wrapper, which
> will ensure that extensions continue to link to libpgport's pqsignal.

Fine by me.

--
nathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-01-14 20:51:58 Re: pgbench error: (setshell) of script 0; execution of meta-command failed
Previous Message Melanie Plageman 2025-01-14 20:35:39 Re: pgsql: Consolidate docs for vacuum-related GUCs in new subsection