[Pgpool-hackers] retry of health check

[Tatsuo Ishii]

> 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?

No. If postgres database does not exist, backend returns 'R' instead
of 'E'.  So pgpool writes 'X' then fails and retries with template1.

> >> 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.

How do you cope with older PostgreSQL version which does not have
postgres database then?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp