public inbox for [email protected]
help / color / mirror / Atom feedFrom: Andres Freund <[email protected]>
To: Thomas Munro <[email protected]>
Cc: [email protected]
Cc: Robert Haas <[email protected]>
Cc: Peter Geoghegan <[email protected]>
Cc: Tom Lane <[email protected]>
Subject: Re: postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier
Date: Thu, 29 Dec 2022 13:54:37 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+hUKGKumpwy+_Zx9_dshccF2HYKqwMCbeeSoOFXy+9ntsh54Q@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<[email protected]>
<CA+hUKGKumpwy+_Zx9_dshccF2HYKqwMCbeeSoOFXy+9ntsh54Q@mail.gmail.com>
Hi,
On 2022-12-30 10:31:22 +1300, Thomas Munro wrote:
> On Fri, Dec 30, 2022 at 6:23 AM Andres Freund <[email protected]> wrote:
> > On 2022-12-08 18:08:15 -0800, Andres Freund wrote:
> > > On 2022-09-25 16:22:37 -0700, Andres Freund wrote:
> > > The only alternative way to provide a wrapper that I can think of are to
> > > a) introduce a new static library that can be linked to by libpqwalreceiver,
> > > postgres_fdw, dblink
> > > b) add a header with static inline functions implementing interrupt-processing
> > > connection establishment for libpq
> > >
> > > Neither really has precedent.
>
> > Any opinions? Due to the simplicity I'm currently leaning to a header-only
> > helper, but I don't feel confident about it.
>
> The header idea is a little bit sneaky (IIUC: a header that is part of
> the core tree, but can't be used by core and possibly needs special
> treatment in 'headercheck' to get the right include search path, can
> only be used by libpqwalreceiver et al which are allowed to link to
> libpq), but I think it is compatible with other goals we have
> discussed in other threads.
Hm, what special search path / headerscheck magic are you thinking of? I think
something like src/include/libpq/libpq-be-fe-helpers.h defining a bunch of
static inlines should "just" work?
We likely could guard against that header being included from code ending up
in the postgres binary directly by #error'ing if BUILDING_DLL is
defined. That's a very badly named define, but it IIRC has to be iff building
code ending up in postgres directly.
> I think in the near future we'll probably remove the concept of non-threaded
> server builds (as proposed before in the post HP-UX 10 cleanup thread, with
> patches, but not quite over the line yet). Then I think the server could be
> allowed to link libpq directly? And at that point this code wouldn't be
> sneaky anymore and could optionally move into a .c. Does that makes sense?
I was wondering about linking in libpq directly as well. But I am not sure
it's a good idea. I suspect we'd run into some issues around libraries
(including extensions) linking to different versions of libpq etc - if we
directly link to libpq that'd end up in tears.
It might be a different story if we had a version of libpq built with
different symbol names etc. But that's not exactly trivial either.
Greetings,
Andres Freund
view thread (7+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox