From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org,
        Robert Haas <robertmhaas@gmail.com>, Peter Geoghegan <pg@bowt.ie>
Subject: Re: postgres_fdw uninterruptible during connection establishment /
 ProcSignalBarrier
In-reply-to: 
 <CA+hUKGKumpwy+_Zx9_dshccF2HYKqwMCbeeSoOFXy+9ntsh54Q@mail.gmail.com>
References: <20220925232237.p6uskba2dw6fnwj2@awork3.anarazel.de>
 <20221209020815.wsoixct72c6hst5l@awork3.anarazel.de>
 <20221229172330.jpuoljhtvivci3cd@awork3.anarazel.de>
 <CA+hUKGKumpwy+_Zx9_dshccF2HYKqwMCbeeSoOFXy+9ntsh54Q@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@gmail.com>
	message dated "Fri, 30 Dec 2022 10:31:22 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <610824.1672349865.1@sss.pgh.pa.us>
Date: Thu, 29 Dec 2022 16:37:45 -0500
Message-ID: <610825.1672349865@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/610825.1672349865%40sss.pgh.pa.us>
Precedence: bulk

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