Re: [Proposal] Add foreign-server health checks infrastructure
От | Kyotaro Horiguchi |
---|---|
Тема | Re: [Proposal] Add foreign-server health checks infrastructure |
Дата | |
Msg-id | 20221017.172642.45253962719866795.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | RE: [Proposal] Add foreign-server health checks infrastructure ("kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>) |
Ответы |
RE: [Proposal] Add foreign-server health checks infrastructure
|
Список | pgsql-hackers |
At Mon, 17 Oct 2022 07:27:21 +0000, "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com> wrote in > > In other words, a variation of pgfdw_connection_check_internal() > > could potentially go into interfaces/libpq/libpq-fe.h > > (backend/libpq/pqcomm.c or src/interfaces/libpq/fe-connect.c). > > Hmm, IIUC libpq related function and data structures cannot be accessed from core source, > so we cannot move to pqcomm.c. > (This is a motivation for introducing libpqwalreceiver library. It is used to avoid to link libpq directly) > And functions in libpq/fe-connect.c will be included libpq.so, > but latch related functions like WaitEventSetWait() should not be called from client application. > So it is also not appropriate. > In short, there are no good position to place the function because this requires both of libpq and core functions. Might be on slight different direction, but it looks to me a bit too much to use WaitEventSet to check only if a socket is live or not. A quick search in the tree told me that we could use pqSocketCheck() instead, and I think it would be the something that "could potentially go into libpq-fe.h" as Önder mentioned, if I understand what he said correctly. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: