Re: [Proposal] Add foreign-server health checks infrastructure
От | Katsuragi Yuta |
---|---|
Тема | Re: [Proposal] Add foreign-server health checks infrastructure |
Дата | |
Msg-id | e0af630a74a02cdd031af52d7f17359e@oss.nttdata.com обсуждение исходный текст |
Ответ на | RE: [Proposal] Add foreign-server health checks infrastructure ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
Ответы |
RE: [Proposal] Add foreign-server health checks infrastructure
|
Список | pgsql-hackers |
On 2023-02-09 23:39, Hayato Kuroda (Fujitsu) wrote: > Dear Katsuragi-san, > > Thank you for reviewing! PSA new version patches. Thank you for updating the patch! These are my comments, please check. 0001: Extending pqSocketPoll seems to be a better way because we can avoid having multiple similar functions. I also would like to hear horiguchi-san's opinion whether this matches his expectation. Improvements of pqSocketPoll/pqSocketCheck is discussed in this thread[1]. I'm concerned with the discussion. As for the function's name, what do you think about keeping current name (pqSocketCheck)? pqSocketIsReadable... describes the functionality very well though. pqConnCheck seems to be a family of pqReadReady or pqWriteRedy, so how about placing pqConnCheck below them? + * Moreover, when neither forRead nor forWrite is requested and timeout is + * disabled, try to check the health of socket. Isn't it better to put the comment on how the arguments are interpreted before the description of return value? +#if defined(POLLRDHUP) + input_fd.events = POLLRDHUP | POLLHUP | POLLNVAL; ... + input_fd.events |= POLLERR; To my understanding, POLLHUP, POLLNVAL and POLLERR are ignored in event. Are they necessary? 0002: As for the return value of postgres_fdw_verify_connection_states, what do you think about returning NULL when connection-checking is not performed? I think there are two cases 1) ConnectionHash is not initialized or 2) connection is not found for specified server name, That is, no entry passes the first if statement below (case 2)). ``` if (all || entry->serverid == serverid) { if (PQconnCheck(entry->conn)) { ``` 0004: I'm wondering if we should add kqueue support in this version, because adding kqueue support introduces additional things to be considered. What do you think about focusing on the main functionality using poll in this patch and going for kqueue support after this patch? [1]: https://www.postgresql.org/message-id/20230209.115009.2229702014236187289.horikyota.ntt%40gmail.com regards, -- Katsuragi Yuta Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: