Re: postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier

Thomas Munro <thomas(dot)munro(at)gmail(dot)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