> On Wed, Mar 10, 2010 at 3:56 PM, Tatsuo Ishii <[email protected]> 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 _______________________________________________ Pgpool-hackers mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-hackers
