[Pgpool-hackers] retry of health check

[Fujii Masao]

On Wed, Mar 10, 2010 at 3:56 PM, Tatsuo Ishii <ishii at sraoss.co.jp> wrote:
> I couldn't find any clear rule in the docs regarding the first
> response from backend. It seems it truely depends on implementaion.

Right.

>> > Anyway, backend then takes the liberty to discconnect the session
>> > after sending above packet and pgpool sees write(2) error. Thus retry
>> > to use "template1" database is correct in this case.
>>
>> I'm not sure if the retry using "template1" database can succeed after
>> write(2) returns an error. If the retry always fails, it's a redundant
>> operation, I think.
>
> Of course the retry will success if backend has template1 but has not
> postgres database. I have tested with such a old version of PostgreSQL.

But, in that case, pgpool never does the retry since it receives the 'E'
(i.e., error meaning nonexistent of postgres database) and doesn't send
the 'X'. No?

>> When write(2) to one of multiple postgres servers under pgpool fails,
>> the retry affects not only that one server but also all of them.
>> Is this behavior intentional?
>
> I can't think of any better way to detect backend failure than as it
> is in current implementation. Do you have better idea?

Personally, I'd like to remove the retry logic since it's confusing,
if it's really redundant operation and doesn't have an use case.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center