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
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 |