| 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: | Whole Thread | Raw Message | 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
| 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 |