Re: postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier - Mailing list pgsql-hackers

From Tom Lane
Subject Re: postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier
Date
Msg-id 610825.1672349865@sss.pgh.pa.us
Whole thread Raw
In response to Re: postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes:
> 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.  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 don't like the idea of linking libpq directly into the backend.
It should remain a dynamically-loaded library to avoid problems 
during software updates.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue)
Next
From: Andres Freund
Date:
Subject: Re: perl 5.36, C99, -Wdeclaration-after-statement -Wshadow=compatible-local