> This seems like a rather expensive solution to a problem that I'm not > really convinced is real. Why should a client program care about the > severity level to a greater extent than whether the message is > ErrorResponse or NoticeResponse? In particular, I'm entirely > unconvinced by your claim that pgpool ought to treat ERROR and FATAL > cases differently.Whatever it does about session termination ought to > be driven by the connection closure, not by the content of the message. > (As a counterexample, what if the backend crashes without delivering any > message at all?)
Pgpool already detects session termination and handles it. BTW, pgpool uses blocking socket and issue select(2), watching read/exception of the file descriptor before reading from the socket. It seems even if the backend teminates the session, select() does not respond immediately but wait forever. I thought in this case select() returns and reading the socket returns EOF. So it seems sometimes it's hard to know if the socket was closed by backend. This is one of the reasons why I don't want entirely rely on the physical session termination event. Moreover what pgpool would like to do here is, better service to users because pgpool is not just a proxy server to PostgreSQL. For example pgpool does failover if one of PostgreSQL nodes goes down. Pgpool can detect postmaster's planning shutdown by watching healthiess of PostgreSQL but it is much better to trigger it by detecting PostgreSQL's admin shutdown case, because it is quicker (less cluster down time) and is more reliable (health check needs to retry before judging postmaster down because of temporary network error or some such). > Moreover, if we did add this starting in 9.3, it would > still be many years before clients could rely on it being provided, > which means you'd need some other solution anyway. Pgpool relies on PostgreSQL and cannot provide services more than what PostgreSQL does. User can do more if he/she uses newer versin of PostgreSQL. This can be said to not only this particlular problem but any other things. > Another issue is that if we do this, we're essentially (IMO) promising > that the set of severity codes won't change in the future, which may > not be a good thing to promise. Why do you care? The list of severity is cleary stated in the document and you cannot arbitality change it without major version change anyway. There's nothing different thing here from any other features what PostgreSQL explicitly provides. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
