On 2024/07/26 22:44, Fujii Masao wrote:
>
>
> On 2024/07/26 17:07, Hayato Kuroda (Fujitsu) wrote:
>> Dear Fujii-san,
>>
>> Just in case - based on the agreement in [1], I updated patches to keep them
>> consistent. We can use same pictures for further discussions...
>
> Thanks for updating the patches! I pushed them.
The buildfarm member "hake" reported a failure in the postgres_fdw regression test.
diff -U3 /export/home/elmer/c15x/buildroot/HEAD/pgsql.build/contrib/postgres_fdw/expected/postgres_fdw.out
/export/home/elmer/c15x/buildroot/HEAD/pgsql.build/contrib/postgres_fdw/results/postgres_fdw.out
--- /export/home/elmer/c15x/buildroot/HEAD/pgsql.build/contrib/postgres_fdw/expected/postgres_fdw.out Fri Jul 26
19:16:292024
+++ /export/home/elmer/c15x/buildroot/HEAD/pgsql.build/contrib/postgres_fdw/results/postgres_fdw.out Fri Jul 26
19:31:122024
@@ -12326,7 +12326,7 @@
FROM postgres_fdw_get_connections(true);
case
------
- 1
+ 0
(1 row)
-- Clean up
The regression.diffs shows that pgfdw_conn_check returned 0 even though pgfdw_conn_checkable()
returned true. This can happen if the "revents" from poll() indicates something other than
POLLRDHUP. I think that "revents" could indicate POLLHUP, POLLERR, or POLLNVAL. Therefore,
IMO pgfdw_conn_check() should be updated as follows. I will test this change.
- return (input_fd.revents & POLLRDHUP) ? 1 : 0;
+ return (input_fd.revents &
+ (POLLRDHUP | POLLHUP | POLLERR | POLLNVAL)) ? 1 : 0;
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION