Re: postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier
Дата
Msg-id 610825.1672349865@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier  (Thomas Munro <thomas.munro@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue)
Следующее
От: Andres Freund
Дата:
Сообщение: Re: perl 5.36, C99, -Wdeclaration-after-statement -Wshadow=compatible-local