Hello Tatsuo,<br><br>Unfortunately, with your patch when A is on (pool_config->health_check_period > 0) and B is on, when retry count is over, failover will be disallowed because of B being on.<br><br>Nenad's patch allows failover to be triggered only by health check. Here is the patch which includes Nenad's fix but also fixes issue with health check timeout not being respected.<br>
<br>Key points in fix for health check timeout being respected are:<br>- in pool_connection_pool.c connect_inet_domain_socket_by_port function, before trying to connect, file descriptor is set to non-blocking mode, and also non-blocking mode error codes are handled, EINPROGRESS and EALREADY (please verify changes here, especially regarding closing fd)<br>
- in main.c health_check_timer_handler has been changed to signal exit_request to health check initiated connect_inet_domain_socket_by_port function call (please verify this, maybe there is a better way to check from connect_inet_domain_socket_by_port if in health_check_timer_expired has been set to 1)<br>
<br>These changes will practically make connect attempt to be non-blocking and repeated until:<br>- connection is made, or<br>- unhandled connection error condition is reached, or<br>- health check timer alarm has been raised, or<br>
- some other exit request (shutdown) has been issued.<br><br>Kind regards,<br>Stevo.<br><br><div class="gmail_quote">2012/1/15 Tatsuo Ishii <span dir="ltr"><<a href="mailto:ishii@postgresql.org">ishii@postgresql.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ok, let me clarify use cases regarding failover.<br>
<br>
Currently there are three parameters:<br>
a) health_check<br>
b) DISALLOW_TO_FAILOVER<br>
c) fail_over_on_backend_error<br>
<br>
Source of errors which can trigger failover are 1)health check 2)write<br>
to backend socket 3)read backend from socket. I represent each 1) as<br>
A, 2) as B, 3) as C.<br>
<br>
1) trigger failover if A or B or C is error<br>
a = on, b = off, c = on<br>
<br>
2) trigger failover only when B or C is error<br>
a = off, b = off, c = on<br>
<br>
3) trigger failover only when B is error<br>
Impossible. Because C error always triggers failover.<br>
<br>
4) trigger failover only when C is error<br>
a = off, b = off, c = off<br>
<br>
5) trigger failover only when A is error(Stevo wants this)<br>
Impossible. Because C error always triggers failover.<br>
<br>
6) never trigger failover<br>
Impossible. Because C error always triggers failover.<br>
<br>
As you can see, C is the problem here (look at #3, #5 and #6)<br>
<br>
If we implemented this:<br>
<div class="im">>> However I think we should disable failover if DISALLOW_TO_FAILOVER set<br>
>> in case of reading data from backend. This should have been done when<br>
>> DISALLOW_TO_FAILOVER was introduced because this is exactly what<br>
>> DISALLOW_TO_FAILOVER tries to accomplish. What do you think?<br>
<br>
</div>1) trigger failover if A or B or C is error<br>
a = on, b = off, c = on<br>
<br>
2) trigger failover only when B or C is error<br>
a = off, b = off, c = on<br>
<br>
3) trigger failover only when B is error<br>
a = off, b = on, c = on<br>
<br>
4) trigger failover only when C is error<br>
a = off, b = off, c = off<br>
<br>
5) trigger failover only when A is error(Stevo wants this)<br>
a = on, b = on, c = off<br>
<br>
6) never trigger failover<br>
a = off, b = on, c = off<br>
<br>
So it seems my patch will solve all the problems including yours.<br>
(timeout while retrying is another issue of course).<br>
<div class="HOEnZb"><div class="h5">--<br>
Tatsuo Ishii<br>
SRA OSS, Inc. Japan<br>
English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
Japanese: <a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
<br>
> I agree, fail_over_on_backend_error isn't useful, just adds confusion by<br>
> overlapping with DISALLOW_TO_FAILOVER.<br>
><br>
> With your patch or without it, it is not possible to failover only on<br>
> health check (max retries) failure. With Nenad's patch, that part works ok<br>
> and I think that patch is semantically ok - failover occurs even though<br>
> DISALLOW_TO_FAILOVER is set for backend but only when health check is<br>
> configured too. Configuring health check without failover on failed health<br>
> check has no purpose. Also health check configured with allowed failover on<br>
> any condition other than health check (max retries) failure has no purpose.<br>
><br>
> Kind regards,<br>
> Stevo.<br>
><br>
> 2012/1/15 Tatsuo Ishii <<a href="mailto:ishii@postgresql.org">ishii@postgresql.org</a>><br>
><br>
>> fail_over_on_backend_error has different meaning from<br>
>> DISALLOW_TO_FAILOVER. From the doc:<br>
>><br>
>> If true, and an error occurs when writing to the backend<br>
>> communication, pgpool-II will trigger the fail over procedure . This<br>
>> is the same behavior as of pgpool-II 2.2.x or earlier. If set to<br>
>> false, pgpool will report an error and disconnect the session.<br>
>><br>
>> This means that if pgpool failed to read from backend, it will trigger<br>
>> failover even if fail_over_on_backend_error to off. So unconditionaly<br>
>> disabling failover will lead backward imcompatibilty.<br>
>><br>
>> However I think we should disable failover if DISALLOW_TO_FAILOVER set<br>
>> in case of reading data from backend. This should have been done when<br>
>> DISALLOW_TO_FAILOVER was introduced because this is exactly what<br>
>> DISALLOW_TO_FAILOVER tries to accomplish. What do you think?<br>
>> --<br>
>> Tatsuo Ishii<br>
>> SRA OSS, Inc. Japan<br>
>> English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
>> Japanese: <a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
>><br>
>> > For a moment I thought we could have set fail_over_on_backend_error to<br>
>> off,<br>
>> > and have backends set with ALLOW_TO_FAILOVER flag. But then I looked in<br>
>> > code.<br>
>> ><br>
>> > In child.c there is a loop child process goes through in its lifetime.<br>
>> When<br>
>> > fatal error condition occurs before child process exits it will call<br>
>> > notice_backend_error which will call degenerate_backend_set which will<br>
>> not<br>
>> > take into account fail_over_on_backend_error is set to off, causing<br>
>> backend<br>
>> > to be degenerated and failover to occur. That's why we have backends set<br>
>> > with DISALLOW_TO_FAILOVER but with our patch applied, health check could<br>
>> > cause failover to occur as expected.<br>
>> ><br>
>> > Maybe it would be enough just to modify degenerate_backend_set, to take<br>
>> > fail_over_on_backend_error into account just like it already takes<br>
>> > DISALLOW_TO_FAILOVER into account.<br>
>> ><br>
>> > Kind regards,<br>
>> > Stevo.<br>
>> ><br>
>> > 2012/1/15 Stevo Slaviĉ <<a href="mailto:sslavic@gmail.com">sslavic@gmail.com</a>><br>
>> ><br>
>> >> Yes and that behaviour which you describe as expected, is not what we<br>
>> >> want. We want pgpool to degrade backend0 and failover when configured<br>
>> max<br>
>> >> health check retries have failed, and to failover only in that case, so<br>
>> not<br>
>> >> sooner e.g. connection/child error condition, but as soon as max health<br>
>> >> check retries have been attempted.<br>
>> >><br>
>> >> Maybe examples will be more clear.<br>
>> >><br>
>> >> Imagine two nodes (node 1 and node 2). On each node a single pgpool and<br>
>> a<br>
>> >> single backend. Apps/clients access db through pgpool on their own node.<br>
>> >> Two backends are configured in postgres native streaming replication.<br>
>> >> pgpools are used in raw mode. Both pgpools have same backend as<br>
>> backend0,<br>
>> >> and same backend as backend1.<br>
>> >> initial state: both backends are up and pgpool can access them, clients<br>
>> >> connect to their pgpool and do their work on master backend, backend0.<br>
>> >><br>
>> >> 1st case: unmodified/non-patched pgpool 3.1.1 is used, backends are<br>
>> >> configured with ALLOW_TO_FAILOVER flag<br>
>> >> - temporary network outage happens between pgpool on node 2 and backend0<br>
>> >> - error condition is reported by child process, and since<br>
>> >> ALLOW_TO_FAILOVER is set, pgpool performs failover without giving<br>
>> chance to<br>
>> >> pgpool health check retries to control whether backend is just<br>
>> temporarily<br>
>> >> inaccessible<br>
>> >> - failover command on node 2 promotes standby backend to a new master -<br>
>> >> split brain occurs, with two masters<br>
>> >><br>
>> >><br>
>> >> 2nd case: unmodified/non-patched pgpool 3.1.1 is used, backends are<br>
>> >> configured with DISALLOW_TO_FAILOVER<br>
>> >> - temporary network outage happens between pgpool on node 2 and backend0<br>
>> >> - error condition is reported by child process, and since<br>
>> >> DISALLOW_TO_FAILOVER is set, pgpool does not perform failover<br>
>> >> - health check gets a chance to check backend0 condition, determines<br>
>> that<br>
>> >> it's not accessible, there will be no health check retries because<br>
>> >> DISALLOW_TO_FAILOVER is set, no failover occurs ever<br>
>> >><br>
>> >><br>
>> >> 3rd case, pgpool 3.1.1 + patch you've sent applied, and backends<br>
>> >> configured with DISALLOW_TO_FAILOVER<br>
>> >> - temporary network outage happens between pgpool on node 2 and backend0<br>
>> >> - error condition is reported by child process, and since<br>
>> >> DISALLOW_TO_FAILOVER is set, pgpool does not perform failover<br>
>> >> - health check gets a chance to check backend0 condition, determines<br>
>> that<br>
>> >> it's not accessible, health check retries happen, and even after max<br>
>> >> retries, no failover happens since failover is disallowed<br>
>> >><br>
>> >><br>
>> >> 4th expected behaviour, pgpool 3.1.1 + patch we sent, and backends<br>
>> >> configured with DISALLOW_TO_FAILOVER<br>
>> >> - temporary network outage happens between pgpool on node 2 and backend0<br>
>> >> - error condition is reported by child process, and since<br>
>> >> DISALLOW_TO_FAILOVER is set, pgpool does not perform failover<br>
>> >> - health check gets a chance to check backend0 condition, determines<br>
>> that<br>
>> >> it's not accessible, health check retries happen, before a max retry<br>
>> >> network condition is cleared, retry happens, and backend0 remains to be<br>
>> >> master, no failover occurs, temporary network issue did not cause split<br>
>> >> brain<br>
>> >> - after some time, temporary network outage happens again between pgpool<br>
>> >> on node 2 and backend0<br>
>> >> - error condition is reported by child process, and since<br>
>> >> DISALLOW_TO_FAILOVER is set, pgpool does not perform failover<br>
>> >> - health check gets a chance to check backend0 condition, determines<br>
>> that<br>
>> >> it's not accessible, health check retries happen, after max retries<br>
>> >> backend0 is still not accessible, failover happens, standby is new<br>
>> master<br>
>> >> and backend0 is degraded<br>
>> >><br>
>> >> Kind regards,<br>
>> >> Stevo.<br>
>> >><br>
>> >><br>
>> >> 2012/1/15 Tatsuo Ishii <<a href="mailto:ishii@postgresql.org">ishii@postgresql.org</a>><br>
>> >><br>
>> >>> In my test evironment, the patch works as expected. I have two<br>
>> >>> backends. Health check retry conf is as follows:<br>
>> >>><br>
>> >>> health_check_max_retries = 3<br>
>> >>> health_check_retry_delay = 1<br>
>> >>><br>
>> >>> 5 09:17:20 LOG: pid 21411: Backend status file /home/t-ishii/work/<br>
>> >>> <a href="http://git.postgresql.org/test/log/pgpool_status" target="_blank">git.postgresql.org/test/log/pgpool_status</a> discarded<br>
>> >>> 2012-01-15 09:17:20 LOG: pid 21411: pgpool-II successfully started.<br>
>> >>> version 3.2alpha1 (hatsuiboshi)<br>
>> >>> 2012-01-15 09:17:20 LOG: pid 21411: find_primary_node: primary node<br>
>> id<br>
>> >>> is 0<br>
>> >>> -- backend1 was shutdown<br>
>> >>><br>
>> >>> 2012-01-15 09:17:50 ERROR: pid 21445:<br>
>> connect_unix_domain_socket_by_port:<br>
>> >>> connect() failed to /tmp/.s.PGSQL.11001: No such file or directory<br>
>> >>> 2012-01-15 09:17:50 ERROR: pid 21445: make_persistent_db_connection:<br>
>> >>> connection to /tmp(11001) failed<br>
>> >>> 2012-01-15 09:17:50 ERROR: pid 21445: check_replication_time_lag: could<br>
>> >>> not connect to DB node 1, check sr_check_user and sr_check_password<br>
>> >>> 2012-01-15 09:17:50 ERROR: pid 21411:<br>
>> connect_unix_domain_socket_by_port:<br>
>> >>> connect() failed to /tmp/.s.PGSQL.11001: No such file or directory<br>
>> >>> 2012-01-15 09:17:50 ERROR: pid 21411: make_persistent_db_connection:<br>
>> >>> connection to /tmp(11001) failed<br>
>> >>> 2012-01-15 09:17:50 ERROR: pid 21411:<br>
>> connect_unix_domain_socket_by_port:<br>
>> >>> connect() failed to /tmp/.s.PGSQL.11001: No such file or directory<br>
>> >>> 2012-01-15 09:17:50 ERROR: pid 21411: make_persistent_db_connection:<br>
>> >>> connection to /tmp(11001) failed<br>
>> >>> -- health check failed<br>
>> >>><br>
>> >>> 2012-01-15 09:17:50 ERROR: pid 21411: health check failed. 1 th host<br>
>> /tmp<br>
>> >>> at port 11001 is down<br>
>> >>> -- start retrying<br>
>> >>> 2012-01-15 09:17:50 LOG: pid 21411: health check retry sleep time: 1<br>
>> >>> second(s)<br>
>> >>> 2012-01-15 09:17:51 ERROR: pid 21411:<br>
>> connect_unix_domain_socket_by_port:<br>
>> >>> connect() failed to /tmp/.s.PGSQL.11001: No such file or directory<br>
>> >>> 2012-01-15 09:17:51 ERROR: pid 21411: make_persistent_db_connection:<br>
>> >>> connection to /tmp(11001) failed<br>
>> >>> 2012-01-15 09:17:51 ERROR: pid 21411: health check failed. 1 th host<br>
>> /tmp<br>
>> >>> at port 11001 is down<br>
>> >>> 2012-01-15 09:17:51 LOG: pid 21411: health check retry sleep time: 1<br>
>> >>> second(s)<br>
>> >>> 2012-01-15 09:17:52 ERROR: pid 21411:<br>
>> connect_unix_domain_socket_by_port:<br>
>> >>> connect() failed to /tmp/.s.PGSQL.11001: No such file or directory<br>
>> >>> 2012-01-15 09:17:52 ERROR: pid 21411: make_persistent_db_connection:<br>
>> >>> connection to /tmp(11001) failed<br>
>> >>> 2012-01-15 09:17:52 ERROR: pid 21411: health check failed. 1 th host<br>
>> /tmp<br>
>> >>> at port 11001 is down<br>
>> >>> 2012-01-15 09:17:52 LOG: pid 21411: health check retry sleep time: 1<br>
>> >>> second(s)<br>
>> >>> 2012-01-15 09:17:53 ERROR: pid 21411:<br>
>> connect_unix_domain_socket_by_port:<br>
>> >>> connect() failed to /tmp/.s.PGSQL.11001: No such file or directory<br>
>> >>> 2012-01-15 09:17:53 ERROR: pid 21411: make_persistent_db_connection:<br>
>> >>> connection to /tmp(11001) failed<br>
>> >>> 2012-01-15 09:17:53 ERROR: pid 21411: health check failed. 1 th host<br>
>> /tmp<br>
>> >>> at port 11001 is down<br>
>> >>> 2012-01-15 09:17:53 LOG: pid 21411: health_check: 1 failover is<br>
>> canceld<br>
>> >>> because failover is disallowed<br>
>> >>> -- after 3 retries, pgpool wanted to failover, but gave up because<br>
>> >>> DISALLOW_TO_FAILOVER is set for backend1<br>
>> >>><br>
>> >>> 2012-01-15 09:18:00 ERROR: pid 21445:<br>
>> connect_unix_domain_socket_by_port:<br>
>> >>> connect() failed to /tmp/.s.PGSQL.11001: No such file or directory<br>
>> >>> 2012-01-15 09:18:00 ERROR: pid 21445: make_persistent_db_connection:<br>
>> >>> connection to /tmp(11001) failed<br>
>> >>> 2012-01-15 09:18:00 ERROR: pid 21445: check_replication_time_lag: could<br>
>> >>> not connect to DB node 1, check sr_check_user and sr_check_password<br>
>> >>> 2012-01-15 09:18:03 ERROR: pid 21411:<br>
>> connect_unix_domain_socket_by_port:<br>
>> >>> connect() failed to /tmp/.s.PGSQL.11001: No such file or directory<br>
>> >>> 2012-01-15 09:18:03 ERROR: pid 21411: make_persistent_db_connection:<br>
>> >>> connection to /tmp(11001) failed<br>
>> >>> 2012-01-15 09:18:03 ERROR: pid 21411: health check failed. 1 th host<br>
>> /tmp<br>
>> >>> at port 11001 is down<br>
>> >>> 2012-01-15 09:18:03 LOG: pid 21411: health check retry sleep time: 1<br>
>> >>> second(s)<br>
>> >>> 2012-01-15 09:18:04 ERROR: pid 21411:<br>
>> connect_unix_domain_socket_by_port:<br>
>> >>> connect() failed to /tmp/.s.PGSQL.11001: No such file or directory<br>
>> >>> 2012-01-15 09:18:04 ERROR: pid 21411: make_persistent_db_connection:<br>
>> >>> connection to /tmp(11001) failed<br>
>> >>> 2012-01-15 09:18:04 ERROR: pid 21411: health check failed. 1 th host<br>
>> /tmp<br>
>> >>> at port 11001 is down<br>
>> >>> 2012-01-15 09:18:04 LOG: pid 21411: health check retry sleep time: 1<br>
>> >>> second(s)<br>
>> >>> 2012-01-15 09:18:05 LOG: pid 21411: after some retrying backend<br>
>> >>> returned to healthy state<br>
>> >>> -- started backend1 and pgpool succeeded in health checking. Resumed<br>
>> >>> using backend1<br>
>> >>> --<br>
>> >>> Tatsuo Ishii<br>
>> >>> SRA OSS, Inc. Japan<br>
>> >>> English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
>> >>> Japanese: <a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
>> >>><br>
>> >>> > Hello Tatsuo,<br>
>> >>> ><br>
>> >>> > Thank you for the patch and effort, but unfortunately this change<br>
>> won't<br>
>> >>> > work for us. We need to set disallow failover to prevent failover on<br>
>> >>> child<br>
>> >>> > reported connection errors (it's ok if few clients lose their<br>
>> >>> connection or<br>
>> >>> > can not connect), and still have pgpool perform failover but only on<br>
>> >>> failed<br>
>> >>> > health check (if configured, after max retries threshold has been<br>
>> >>> reached).<br>
>> >>> ><br>
>> >>> > Maybe it would be best to add an extra value for backend_flag -<br>
>> >>> > ALLOW_TO_FAILOVER_ON_HEALTH_CHECK or<br>
>> >>> DISALLOW_TO_FAILOVER_ON_CHILD_ERROR.<br>
>> >>> > It should behave same as DISALLOW_TO_FAILOVER is set, with only<br>
>> >>> difference<br>
>> >>> > in behaviour when health check (if set, max retries) has failed -<br>
>> unlike<br>
>> >>> > DISALLOW_TO_FAILOVER, this new flag should allow failover in this<br>
>> case<br>
>> >>> only.<br>
>> >>> ><br>
>> >>> > Without this change health check (especially health check retries)<br>
>> >>> doesn't<br>
>> >>> > make much sense - child error is more likely to occur on (temporary)<br>
>> >>> > backend failure then health check and will or will not cause<br>
>> failover to<br>
>> >>> > occur depending on backend flag, without giving health check retries<br>
>> a<br>
>> >>> > chance to determine if failure was temporary or not, risking split<br>
>> brain<br>
>> >>> > situation with two masters just because of temporary network link<br>
>> >>> hiccup.<br>
>> >>> ><br>
>> >>> > Our main problem remains though with the health check timeout not<br>
>> being<br>
>> >>> > respected in these special conditions we have. Maybe Nenad can help<br>
>> you<br>
>> >>> > more to reproduce the issue on your environment.<br>
>> >>> ><br>
>> >>> > Kind regards,<br>
>> >>> > Stevo.<br>
>> >>> ><br>
>> >>> > 2012/1/13 Tatsuo Ishii <<a href="mailto:ishii@postgresql.org">ishii@postgresql.org</a>><br>
>> >>> ><br>
>> >>> >> Thanks for pointing it out.<br>
>> >>> >> Yes, checking DISALLOW_TO_FAILOVER before retrying is wrong.<br>
>> >>> >> However, after retry count over, we should check<br>
>> DISALLOW_TO_FAILOVER I<br>
>> >>> >> think.<br>
>> >>> >> Attached is the patch attempt to fix it. Please try.<br>
>> >>> >> --<br>
>> >>> >> Tatsuo Ishii<br>
>> >>> >> SRA OSS, Inc. Japan<br>
>> >>> >> English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
>> >>> >> Japanese: <a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
>> >>> >><br>
>> >>> >> > pgpool is being used in raw mode - just for (health check based)<br>
>> >>> failover<br>
>> >>> >> > part, so applications are not required to restart when standby<br>
>> gets<br>
>> >>> >> > promoted to new master. Here is pgpool.conf file and a very small<br>
>> >>> patch<br>
>> >>> >> > we're using applied to pgpool 3.1.1 release.<br>
>> >>> >> ><br>
>> >>> >> > We have to have DISALLOW_TO_FAILOVER set for the backend since any<br>
>> >>> child<br>
>> >>> >> > process that detects condition that master/backend0 is not<br>
>> >>> available, if<br>
>> >>> >> > DISALLOW_TO_FAILOVER was not set, will degenerate backend without<br>
>> >>> giving<br>
>> >>> >> > health check a chance to retry. We need health check with retries<br>
>> >>> because<br>
>> >>> >> > condition that backend0 is not available could be temporary<br>
>> (network<br>
>> >>> >> > glitches to the remote site where master is, or deliberate<br>
>> failover<br>
>> >>> of<br>
>> >>> >> > master postgres service from one node to the other on remote site<br>
>> -<br>
>> >>> in<br>
>> >>> >> both<br>
>> >>> >> > cases remote means remote to the pgpool that is going to perform<br>
>> >>> health<br>
>> >>> >> > checks and ultimately the failover) and we don't want standby to<br>
>> be<br>
>> >>> >> > promoted as easily to a new master, to prevent temporary network<br>
>> >>> >> conditions<br>
>> >>> >> > which could occur frequently to frequently cause split brain with<br>
>> two<br>
>> >>> >> > masters.<br>
>> >>> >> ><br>
>> >>> >> > But then, with DISALLOW_TO_FAILOVER set, without the patch health<br>
>> >>> check<br>
>> >>> >> > will not retry and will thus give only one chance to backend (if<br>
>> >>> health<br>
>> >>> >> > check ever occurs before child process failure to connect to the<br>
>> >>> >> backend),<br>
>> >>> >> > rendering retry settings effectively to be ignored. That's where<br>
>> this<br>
>> >>> >> patch<br>
>> >>> >> > comes into action - enables health check retries while child<br>
>> >>> processes<br>
>> >>> >> are<br>
>> >>> >> > prevented to degenerate backend.<br>
>> >>> >> ><br>
>> >>> >> > I don't think, but I could be wrong, that this patch influences<br>
>> the<br>
>> >>> >> > behavior we're seeing with unwanted health check attempt delays.<br>
>> >>> Also,<br>
>> >>> >> > knowing this, maybe pgpool could be patched or some other support<br>
>> be<br>
>> >>> >> built<br>
>> >>> >> > into it to cover this use case.<br>
>> >>> >> ><br>
>> >>> >> > Regards,<br>
>> >>> >> > Stevo.<br>
>> >>> >> ><br>
>> >>> >> ><br>
>> >>> >> > 2012/1/12 Tatsuo Ishii <<a href="mailto:ishii@postgresql.org">ishii@postgresql.org</a>><br>
>> >>> >> ><br>
>> >>> >> >> I have accepted the moderation request. Your post should be sent<br>
>> >>> >> shortly.<br>
>> >>> >> >> Also I have raised the post size limit to 1MB.<br>
>> >>> >> >> I will look into this...<br>
>> >>> >> >> --<br>
>> >>> >> >> Tatsuo Ishii<br>
>> >>> >> >> SRA OSS, Inc. Japan<br>
>> >>> >> >> English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
>> >>> >> >> Japanese: <a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
>> >>> >> >><br>
>> >>> >> >> > Here is the log file and strace output file (this time in an<br>
>> >>> archive,<br>
>> >>> >> >> > didn't know about 200KB constraint on post size which requires<br>
>> >>> >> moderator<br>
>> >>> >> >> > approval). Timings configured are 30sec health check interval,<br>
>> >>> 5sec<br>
>> >>> >> >> > timeout, and 2 retries with 10sec retry delay.<br>
>> >>> >> >> ><br>
>> >>> >> >> > It takes a lot more than 5sec from started health check to<br>
>> >>> sleeping<br>
>> >>> >> 10sec<br>
>> >>> >> >> > for first retry.<br>
>> >>> >> >> ><br>
>> >>> >> >> > Seen in code (main.x, health_check() function), within (retry)<br>
>> >>> attempt<br>
>> >>> >> >> > there is inner retry (first with postgres database then with<br>
>> >>> >> template1)<br>
>> >>> >> >> and<br>
>> >>> >> >> > that part doesn't seem to be interrupted by alarm.<br>
>> >>> >> >> ><br>
>> >>> >> >> > Regards,<br>
>> >>> >> >> > Stevo.<br>
>> >>> >> >> ><br>
>> >>> >> >> > 2012/1/12 Stevo Slaviĉ <<a href="mailto:sslavic@gmail.com">sslavic@gmail.com</a>><br>
>> >>> >> >> ><br>
>> >>> >> >> >> Here is the log file and strace output file. Timings<br>
>> configured<br>
>> >>> are<br>
>> >>> >> >> 30sec<br>
>> >>> >> >> >> health check interval, 5sec timeout, and 2 retries with 10sec<br>
>> >>> retry<br>
>> >>> >> >> delay.<br>
>> >>> >> >> >><br>
>> >>> >> >> >> It takes a lot more than 5sec from started health check to<br>
>> >>> sleeping<br>
>> >>> >> >> 10sec<br>
>> >>> >> >> >> for first retry.<br>
>> >>> >> >> >><br>
>> >>> >> >> >> Seen in code (main.x, health_check() function), within (retry)<br>
>> >>> >> attempt<br>
>> >>> >> >> >> there is inner retry (first with postgres database then with<br>
>> >>> >> template1)<br>
>> >>> >> >> and<br>
>> >>> >> >> >> that part doesn't seem to be interrupted by alarm.<br>
>> >>> >> >> >><br>
>> >>> >> >> >> Regards,<br>
>> >>> >> >> >> Stevo.<br>
>> >>> >> >> >><br>
>> >>> >> >> >><br>
>> >>> >> >> >> 2012/1/11 Tatsuo Ishii <<a href="mailto:ishii@postgresql.org">ishii@postgresql.org</a>><br>
>> >>> >> >> >><br>
>> >>> >> >> >>> Ok, I will do it. In the mean time you could use "strace -tt<br>
>> -p<br>
>> >>> PID"<br>
>> >>> >> >> >>> to see which system call is blocked.<br>
>> >>> >> >> >>> --<br>
>> >>> >> >> >>> Tatsuo Ishii<br>
>> >>> >> >> >>> SRA OSS, Inc. Japan<br>
>> >>> >> >> >>> English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
>> >>> >> >> >>> Japanese: <a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
>> >>> >> >> >>><br>
>> >>> >> >> >>> > OK, got the info - key point is that ip forwarding is<br>
>> >>> disabled for<br>
>> >>> >> >> >>> security<br>
>> >>> >> >> >>> > reasons. Rules in iptables are not important, iptables can<br>
>> be<br>
>> >>> >> >> stopped,<br>
>> >>> >> >> >>> or<br>
>> >>> >> >> >>> > previously added rules removed.<br>
>> >>> >> >> >>> ><br>
>> >>> >> >> >>> > Here are the steps to reproduce (kudos to my colleague<br>
>> Nenad<br>
>> >>> >> >> Bulatovic<br>
>> >>> >> >> >>> for<br>
>> >>> >> >> >>> > providing this):<br>
>> >>> >> >> >>> ><br>
>> >>> >> >> >>> > 1.) make sure that ip forwarding is off:<br>
>> >>> >> >> >>> > echo 0 > /proc/sys/net/ipv4/ip_forward<br>
>> >>> >> >> >>> > 2.) create IP alias on some interface (and have postgres<br>
>> >>> listen on<br>
>> >>> >> >> it):<br>
>> >>> >> >> >>> > ip addr add x.x.x.x/yy dev ethz<br>
>> >>> >> >> >>> > 3.) set backend_hostname0 to aforementioned IP<br>
>> >>> >> >> >>> > 4.) start pgpool and monitor health checks<br>
>> >>> >> >> >>> > 5.) remove IP alias:<br>
>> >>> >> >> >>> > ip addr del x.x.x.x/yy dev ethz<br>
>> >>> >> >> >>> ><br>
>> >>> >> >> >>> ><br>
>> >>> >> >> >>> > Here is the interesting part in pgpool log after this:<br>
>> >>> >> >> >>> > 2012-01-11 17:38:04 DEBUG: pid 24358: starting health<br>
>> checking<br>
>> >>> >> >> >>> > 2012-01-11 17:38:04 DEBUG: pid 24358: health_check: 0 th DB<br>
>> >>> node<br>
>> >>> >> >> >>> status: 2<br>
>> >>> >> >> >>> > 2012-01-11 17:38:04 DEBUG: pid 24358: health_check: 1 th DB<br>
>> >>> node<br>
>> >>> >> >> >>> status: 1<br>
>> >>> >> >> >>> > 2012-01-11 17:38:34 DEBUG: pid 24358: starting health<br>
>> checking<br>
>> >>> >> >> >>> > 2012-01-11 17:38:34 DEBUG: pid 24358: health_check: 0 th DB<br>
>> >>> node<br>
>> >>> >> >> >>> status: 2<br>
>> >>> >> >> >>> > 2012-01-11 17:41:43 DEBUG: pid 24358: health_check: 0 th DB<br>
>> >>> node<br>
>> >>> >> >> >>> status: 2<br>
>> >>> >> >> >>> > 2012-01-11 17:41:46 ERROR: pid 24358: health check failed.<br>
>> 0<br>
>> >>> th<br>
>> >>> >> host<br>
>> >>> >> >> >>> > 192.168.2.27 at port 5432 is down<br>
>> >>> >> >> >>> > 2012-01-11 17:41:46 LOG: pid 24358: health check retry<br>
>> sleep<br>
>> >>> >> time:<br>
>> >>> >> >> 10<br>
>> >>> >> >> >>> > second(s)<br>
>> >>> >> >> >>> ><br>
>> >>> >> >> >>> > That pgpool was configured with health check interval of<br>
>> >>> 30sec,<br>
>> >>> >> 5sec<br>
>> >>> >> >> >>> > timeout, and 10sec retry delay with 2 max retries.<br>
>> >>> >> >> >>> ><br>
>> >>> >> >> >>> > Making use of libpq instead for connecting to db in health<br>
>> >>> checks<br>
>> >>> >> IMO<br>
>> >>> >> >> >>> > should resolve it, but you'll best determine which call<br>
>> >>> exactly<br>
>> >>> >> gets<br>
>> >>> >> >> >>> > blocked waiting. Btw, psql with PGCONNECT_TIMEOUT env var<br>
>> >>> >> configured<br>
>> >>> >> >> >>> > respects that env var timeout.<br>
>> >>> >> >> >>> ><br>
>> >>> >> >> >>> > Regards,<br>
>> >>> >> >> >>> > Stevo.<br>
>> >>> >> >> >>> ><br>
>> >>> >> >> >>> > On Wed, Jan 11, 2012 at 11:15 AM, Stevo Slaviĉ <<br>
>> >>> <a href="mailto:sslavic@gmail.com">sslavic@gmail.com</a><br>
>> >>> >> ><br>
>> >>> >> >> >>> wrote:<br>
>> >>> >> >> >>> ><br>
>> >>> >> >> >>> >> Tatsuo,<br>
>> >>> >> >> >>> >><br>
>> >>> >> >> >>> >> Did you restart iptables after adding rule?<br>
>> >>> >> >> >>> >><br>
>> >>> >> >> >>> >> Regards,<br>
>> >>> >> >> >>> >> Stevo.<br>
>> >>> >> >> >>> >><br>
>> >>> >> >> >>> >><br>
>> >>> >> >> >>> >> On Wed, Jan 11, 2012 at 11:12 AM, Stevo Slaviĉ <<br>
>> >>> >> <a href="mailto:sslavic@gmail.com">sslavic@gmail.com</a>><br>
>> >>> >> >> >>> wrote:<br>
>> >>> >> >> >>> >><br>
>> >>> >> >> >>> >>> Looking into this to verify if these are all necessary<br>
>> >>> changes<br>
>> >>> >> to<br>
>> >>> >> >> have<br>
>> >>> >> >> >>> >>> port unreachable message silently rejected (suspecting<br>
>> some<br>
>> >>> >> kernel<br>
>> >>> >> >> >>> >>> parameter tuning is needed).<br>
>> >>> >> >> >>> >>><br>
>> >>> >> >> >>> >>> Just to clarify it's not a problem that host is being<br>
>> >>> detected<br>
>> >>> >> by<br>
>> >>> >> >> >>> pgpool<br>
>> >>> >> >> >>> >>> to be down, but the timing when that happens. On<br>
>> environment<br>
>> >>> >> where<br>
>> >>> >> >> >>> issue is<br>
>> >>> >> >> >>> >>> reproduced pgpool as part of health check attempt tries<br>
>> to<br>
>> >>> >> connect<br>
>> >>> >> >> to<br>
>> >>> >> >> >>> >>> backend and hangs for tcp timeout instead of being<br>
>> >>> interrupted<br>
>> >>> >> by<br>
>> >>> >> >> >>> timeout<br>
>> >>> >> >> >>> >>> alarm. Can you verify/confirm please the health check<br>
>> retry<br>
>> >>> >> timings<br>
>> >>> >> >> >>> are not<br>
>> >>> >> >> >>> >>> delayed?<br>
>> >>> >> >> >>> >>><br>
>> >>> >> >> >>> >>> Regards,<br>
>> >>> >> >> >>> >>> Stevo.<br>
>> >>> >> >> >>> >>><br>
>> >>> >> >> >>> >>><br>
>> >>> >> >> >>> >>> On Wed, Jan 11, 2012 at 10:50 AM, Tatsuo Ishii <<br>
>> >>> >> >> <a href="mailto:ishii@postgresql.org">ishii@postgresql.org</a><br>
>> >>> >> >> >>> >wrote:<br>
>> >>> >> >> >>> >>><br>
>> >>> >> >> >>> >>>> Ok, I did:<br>
>> >>> >> >> >>> >>>><br>
>> >>> >> >> >>> >>>> # iptables -A FORWARD -j REJECT --reject-with<br>
>> >>> >> >> icmp-port-unreachable<br>
>> >>> >> >> >>> >>>><br>
>> >>> >> >> >>> >>>> on the host where pgpoo is running. And pull network<br>
>> cable<br>
>> >>> from<br>
>> >>> >> >> >>> >>>> backend0 host network interface. Pgpool detected the<br>
>> host<br>
>> >>> being<br>
>> >>> >> >> down<br>
>> >>> >> >> >>> >>>> as expected...<br>
>> >>> >> >> >>> >>>> --<br>
>> >>> >> >> >>> >>>> Tatsuo Ishii<br>
>> >>> >> >> >>> >>>> SRA OSS, Inc. Japan<br>
>> >>> >> >> >>> >>>> English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
>> >>> >> >> >>> >>>> Japanese: <a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
>> >>> >> >> >>> >>>><br>
>> >>> >> >> >>> >>>> > Backend is not destination of this message, pgpool<br>
>> host<br>
>> >>> is,<br>
>> >>> >> and<br>
>> >>> >> >> we<br>
>> >>> >> >> >>> >>>> don't<br>
>> >>> >> >> >>> >>>> > want it to ever get it. With command I've sent you<br>
>> rule<br>
>> >>> will<br>
>> >>> >> be<br>
>> >>> >> >> >>> >>>> created for<br>
>> >>> >> >> >>> >>>> > any source and destination.<br>
>> >>> >> >> >>> >>>> ><br>
>> >>> >> >> >>> >>>> > Regards,<br>
>> >>> >> >> >>> >>>> > Stevo.<br>
>> >>> >> >> >>> >>>> ><br>
>> >>> >> >> >>> >>>> > On Wed, Jan 11, 2012 at 10:38 AM, Tatsuo Ishii <<br>
>> >>> >> >> >>> <a href="mailto:ishii@postgresql.org">ishii@postgresql.org</a>><br>
>> >>> >> >> >>> >>>> wrote:<br>
>> >>> >> >> >>> >>>> ><br>
>> >>> >> >> >>> >>>> >> I did following:<br>
>> >>> >> >> >>> >>>> >><br>
>> >>> >> >> >>> >>>> >> Do following on the host where pgpool is running on:<br>
>> >>> >> >> >>> >>>> >><br>
>> >>> >> >> >>> >>>> >> # iptables -A FORWARD -j REJECT --reject-with<br>
>> >>> >> >> >>> icmp-port-unreachable -d<br>
>> >>> >> >> >>> >>>> >> 133.137.177.124<br>
>> >>> >> >> >>> >>>> >> (133.137.177.124 is the host where backend is running<br>
>> >>> on)<br>
>> >>> >> >> >>> >>>> >><br>
>> >>> >> >> >>> >>>> >> Pull network cable from backend0 host network<br>
>> interface.<br>
>> >>> >> Pgpool<br>
>> >>> >> >> >>> >>>> >> detected the host being down as expected. Am I<br>
>> missing<br>
>> >>> >> >> something?<br>
>> >>> >> >> >>> >>>> >> --<br>
>> >>> >> >> >>> >>>> >> Tatsuo Ishii<br>
>> >>> >> >> >>> >>>> >> SRA OSS, Inc. Japan<br>
>> >>> >> >> >>> >>>> >> English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
>> >>> >> >> >>> >>>> >> Japanese: <a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
>> >>> >> >> >>> >>>> >><br>
>> >>> >> >> >>> >>>> >> > Hello Tatsuo,<br>
>> >>> >> >> >>> >>>> >> ><br>
>> >>> >> >> >>> >>>> >> > With backend0 on one host just configure following<br>
>> >>> rule on<br>
>> >>> >> >> other<br>
>> >>> >> >> >>> >>>> host<br>
>> >>> >> >> >>> >>>> >> where<br>
>> >>> >> >> >>> >>>> >> > pgpool is:<br>
>> >>> >> >> >>> >>>> >> ><br>
>> >>> >> >> >>> >>>> >> > iptables -A FORWARD -j REJECT --reject-with<br>
>> >>> >> >> >>> icmp-port-unreachable<br>
>> >>> >> >> >>> >>>> >> ><br>
>> >>> >> >> >>> >>>> >> > and then have pgpool startup with health checking<br>
>> and<br>
>> >>> >> >> retrying<br>
>> >>> >> >> >>> >>>> >> configured,<br>
>> >>> >> >> >>> >>>> >> > and then pull network cable from backend0 host<br>
>> network<br>
>> >>> >> >> >>> interface.<br>
>> >>> >> >> >>> >>>> >> ><br>
>> >>> >> >> >>> >>>> >> > Regards,<br>
>> >>> >> >> >>> >>>> >> > Stevo.<br>
>> >>> >> >> >>> >>>> >> ><br>
>> >>> >> >> >>> >>>> >> > On Wed, Jan 11, 2012 at 6:27 AM, Tatsuo Ishii <<br>
>> >>> >> >> >>> <a href="mailto:ishii@postgresql.org">ishii@postgresql.org</a><br>
>> >>> >> >> >>> >>>> ><br>
>> >>> >> >> >>> >>>> >> wrote:<br>
>> >>> >> >> >>> >>>> >> ><br>
>> >>> >> >> >>> >>>> >> >> I want to try to test the situation you descrived:<br>
>> >>> >> >> >>> >>>> >> >><br>
>> >>> >> >> >>> >>>> >> >> >> > When system is configured for security<br>
>> reasons<br>
>> >>> not<br>
>> >>> >> to<br>
>> >>> >> >> >>> return<br>
>> >>> >> >> >>> >>>> >> >> destination<br>
>> >>> >> >> >>> >>>> >> >> >> > host unreachable messages, even though<br>
>> >>> >> >> >>> health_check_timeout is<br>
>> >>> >> >> >>> >>>> >> >><br>
>> >>> >> >> >>> >>>> >> >> But I don't know how to do it. I pulled out the<br>
>> >>> network<br>
>> >>> >> >> cable<br>
>> >>> >> >> >>> and<br>
>> >>> >> >> >>> >>>> >> >> pgpool detected it as expected. Also I configured<br>
>> the<br>
>> >>> >> server<br>
>> >>> >> >> >>> which<br>
>> >>> >> >> >>> >>>> >> >> PostgreSQL is running on to disable the 5432<br>
>> port. In<br>
>> >>> >> this<br>
>> >>> >> >> case<br>
>> >>> >> >> >>> >>>> >> >> connect(2) returned EHOSTUNREACH (No route to<br>
>> host)<br>
>> >>> so<br>
>> >>> >> >> pgpool<br>
>> >>> >> >> >>> >>>> detected<br>
>> >>> >> >> >>> >>>> >> >> the error as expected.<br>
>> >>> >> >> >>> >>>> >> >><br>
>> >>> >> >> >>> >>>> >> >> Could you please instruct me?<br>
>> >>> >> >> >>> >>>> >> >> --<br>
>> >>> >> >> >>> >>>> >> >> Tatsuo Ishii<br>
>> >>> >> >> >>> >>>> >> >> SRA OSS, Inc. Japan<br>
>> >>> >> >> >>> >>>> >> >> English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
>> >>> >> >> >>> >>>> >> >> Japanese: <a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
>> >>> >> >> >>> >>>> >> >><br>
>> >>> >> >> >>> >>>> >> >> > Hello Tatsuo,<br>
>> >>> >> >> >>> >>>> >> >> ><br>
>> >>> >> >> >>> >>>> >> >> > Thank you for replying!<br>
>> >>> >> >> >>> >>>> >> >> ><br>
>> >>> >> >> >>> >>>> >> >> > I'm not sure what exactly is blocking, just by<br>
>> >>> pgpool<br>
>> >>> >> code<br>
>> >>> >> >> >>> >>>> analysis I<br>
>> >>> >> >> >>> >>>> >> >> > suspect it is the part where a connection is<br>
>> made<br>
>> >>> to<br>
>> >>> >> the<br>
>> >>> >> >> db<br>
>> >>> >> >> >>> and<br>
>> >>> >> >> >>> >>>> it<br>
>> >>> >> >> >>> >>>> >> >> doesn't<br>
>> >>> >> >> >>> >>>> >> >> > seem to get interrupted by alarm. Tested<br>
>> thoroughly<br>
>> >>> >> health<br>
>> >>> >> >> >>> check<br>
>> >>> >> >> >>> >>>> >> >> behaviour,<br>
>> >>> >> >> >>> >>>> >> >> > it works really well when host/ip is there and<br>
>> just<br>
>> >>> >> >> >>> >>>> backend/postgres<br>
>> >>> >> >> >>> >>>> >> is<br>
>> >>> >> >> >>> >>>> >> >> > down, but not when backend host/ip is down. I<br>
>> could<br>
>> >>> >> see in<br>
>> >>> >> >> >>> log<br>
>> >>> >> >> >>> >>>> that<br>
>> >>> >> >> >>> >>>> >> >> initial<br>
>> >>> >> >> >>> >>>> >> >> > health check and each retry got delayed when<br>
>> >>> host/ip is<br>
>> >>> >> >> not<br>
>> >>> >> >> >>> >>>> reachable,<br>
>> >>> >> >> >>> >>>> >> >> > while when just backend is not listening (is<br>
>> down)<br>
>> >>> on<br>
>> >>> >> the<br>
>> >>> >> >> >>> >>>> reachable<br>
>> >>> >> >> >>> >>>> >> >> host/ip<br>
>> >>> >> >> >>> >>>> >> >> > then initial health check and all retries are<br>
>> >>> exact to<br>
>> >>> >> the<br>
>> >>> >> >> >>> >>>> settings in<br>
>> >>> >> >> >>> >>>> >> >> > pgpool.conf.<br>
>> >>> >> >> >>> >>>> >> >> ><br>
>> >>> >> >> >>> >>>> >> >> > PGCONNECT_TIMEOUT is listed as one of the libpq<br>
>> >>> >> >> environment<br>
>> >>> >> >> >>> >>>> variables<br>
>> >>> >> >> >>> >>>> >> in<br>
>> >>> >> >> >>> >>>> >> >> > the docs (see<br>
>> >>> >> >> >>> >>>> >> >><br>
>> >>> >> <a href="http://www.postgresql.org/docs/9.1/static/libpq-envars.html" target="_blank">http://www.postgresql.org/docs/9.1/static/libpq-envars.html</a>)<br>
>> >>> >> >> >>> >>>> >> >> > There is equivalent parameter in libpq<br>
>> >>> >> PGconnectdbParams (<br>
>> >>> >> >> >>> see<br>
>> >>> >> >> >>> >>>> >> >> ><br>
>> >>> >> >> >>> >>>> >> >><br>
>> >>> >> >> >>> >>>> >><br>
>> >>> >> >> >>> >>>><br>
>> >>> >> >> >>><br>
>> >>> >> >><br>
>> >>> >><br>
>> >>><br>
>> <a href="http://www.postgresql.org/docs/9.1/static/libpq-connect.html#LIBPQ-CONNECT-CONNECT-TIMEOUT" target="_blank">http://www.postgresql.org/docs/9.1/static/libpq-connect.html#LIBPQ-CONNECT-CONNECT-TIMEOUT</a><br>
>> >>> >> >> >>> >>>> >> >> )<br>
>> >>> >> >> >>> >>>> >> >> > At the beginning of that same page there are<br>
>> some<br>
>> >>> >> >> important<br>
>> >>> >> >> >>> >>>> infos on<br>
>> >>> >> >> >>> >>>> >> >> using<br>
>> >>> >> >> >>> >>>> >> >> > these functions.<br>
>> >>> >> >> >>> >>>> >> >> ><br>
>> >>> >> >> >>> >>>> >> >> > psql respects PGCONNECT_TIMEOUT.<br>
>> >>> >> >> >>> >>>> >> >> ><br>
>> >>> >> >> >>> >>>> >> >> > Regards,<br>
>> >>> >> >> >>> >>>> >> >> > Stevo.<br>
>> >>> >> >> >>> >>>> >> >> ><br>
>> >>> >> >> >>> >>>> >> >> > On Wed, Jan 11, 2012 at 12:13 AM, Tatsuo Ishii <<br>
>> >>> >> >> >>> >>>> <a href="mailto:ishii@postgresql.org">ishii@postgresql.org</a>><br>
>> >>> >> >> >>> >>>> >> >> wrote:<br>
>> >>> >> >> >>> >>>> >> >> ><br>
>> >>> >> >> >>> >>>> >> >> >> > Hello pgpool community,<br>
>> >>> >> >> >>> >>>> >> >> >> ><br>
>> >>> >> >> >>> >>>> >> >> >> > When system is configured for security<br>
>> reasons<br>
>> >>> not<br>
>> >>> >> to<br>
>> >>> >> >> >>> return<br>
>> >>> >> >> >>> >>>> >> >> destination<br>
>> >>> >> >> >>> >>>> >> >> >> > host unreachable messages, even though<br>
>> >>> >> >> >>> health_check_timeout is<br>
>> >>> >> >> >>> >>>> >> >> >> configured,<br>
>> >>> >> >> >>> >>>> >> >> >> > socket call will block and alarm will not get<br>
>> >>> raised<br>
>> >>> >> >> >>> until TCP<br>
>> >>> >> >> >>> >>>> >> timeout<br>
>> >>> >> >> >>> >>>> >> >> >> > occurs.<br>
>> >>> >> >> >>> >>>> >> >> >><br>
>> >>> >> >> >>> >>>> >> >> >> Interesting. So are you saying that read(2)<br>
>> >>> cannot be<br>
>> >>> >> >> >>> >>>> interrupted by<br>
>> >>> >> >> >>> >>>> >> >> >> alarm signal if the system is configured not to<br>
>> >>> return<br>
>> >>> >> >> >>> >>>> destination<br>
>> >>> >> >> >>> >>>> >> >> >> host unreachable message? Could you please<br>
>> guide<br>
>> >>> me<br>
>> >>> >> >> where I<br>
>> >>> >> >> >>> can<br>
>> >>> >> >> >>> >>>> get<br>
>> >>> >> >> >>> >>>> >> >> >> such that info? (I'm not a network expert).<br>
>> >>> >> >> >>> >>>> >> >> >><br>
>> >>> >> >> >>> >>>> >> >> >> > Not a C programmer, found some info that<br>
>> select<br>
>> >>> call<br>
>> >>> >> >> >>> could be<br>
>> >>> >> >> >>> >>>> >> replace<br>
>> >>> >> >> >>> >>>> >> >> >> with<br>
>> >>> >> >> >>> >>>> >> >> >> > select/pselect calls. Maybe it would be best<br>
>> if<br>
>> >>> >> >> >>> >>>> PGCONNECT_TIMEOUT<br>
>> >>> >> >> >>> >>>> >> >> value<br>
>> >>> >> >> >>> >>>> >> >> >> > could be used here for connection timeout.<br>
>> >>> pgpool<br>
>> >>> >> has<br>
>> >>> >> >> >>> libpq as<br>
>> >>> >> >> >>> >>>> >> >> >> dependency,<br>
>> >>> >> >> >>> >>>> >> >> >> > why isn't it using libpq for the healthcheck<br>
>> db<br>
>> >>> >> connect<br>
>> >>> >> >> >>> >>>> calls, then<br>
>> >>> >> >> >>> >>>> >> >> >> > PGCONNECT_TIMEOUT would be applied?<br>
>> >>> >> >> >>> >>>> >> >> >><br>
>> >>> >> >> >>> >>>> >> >> >> I don't think libpq uses select/pselect for<br>
>> >>> >> establishing<br>
>> >>> >> >> >>> >>>> connection,<br>
>> >>> >> >> >>> >>>> >> >> >> but using libpq instead of homebrew code seems<br>
>> to<br>
>> >>> be<br>
>> >>> >> an<br>
>> >>> >> >> >>> idea.<br>
>> >>> >> >> >>> >>>> Let me<br>
>> >>> >> >> >>> >>>> >> >> >> think about it.<br>
>> >>> >> >> >>> >>>> >> >> >><br>
>> >>> >> >> >>> >>>> >> >> >> One question. Are you sure that libpq can deal<br>
>> >>> with<br>
>> >>> >> the<br>
>> >>> >> >> case<br>
>> >>> >> >> >>> >>>> (not to<br>
>> >>> >> >> >>> >>>> >> >> >> return destination host unreachable messages)<br>
>> by<br>
>> >>> using<br>
>> >>> >> >> >>> >>>> >> >> >> PGCONNECT_TIMEOUT?<br>
>> >>> >> >> >>> >>>> >> >> >> --<br>
>> >>> >> >> >>> >>>> >> >> >> Tatsuo Ishii<br>
>> >>> >> >> >>> >>>> >> >> >> SRA OSS, Inc. Japan<br>
>> >>> >> >> >>> >>>> >> >> >> English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
>> >>> >> >> >>> >>>> >> >> >> Japanese: <a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
>> >>> >> >> >>> >>>> >> >> >><br>
>> >>> >> >> >>> >>>> >> >><br>
>> >>> >> >> >>> >>>> >><br>
>> >>> >> >> >>> >>>><br>
>> >>> >> >> >>> >>><br>
>> >>> >> >> >>> >>><br>
>> >>> >> >> >>> >><br>
>> >>> >> >> >>><br>
>> >>> >> >> >><br>
>> >>> >> >> >><br>
>> >>> >> >><br>
>> >>> >><br>
>> >>><br>
>> >><br>
>> >><br>
>><br>
</div></div></blockquote></div><br>