Обсуждение: Proposal: add new field to ErrorResponse and NoticeResponse
I described the problem with possibly localized "S" filed of ErrorResponse(and NoticeResponse) in Frontend/Backend protocol. http://archives.postgresql.org/pgsql-hackers/2012-05/msg00912.php So I would like to propose a solution for this (for 9.3): add new field to ErrorResponse and NoticeResponse. The new field will have the same value as "S" except that it's never localized. This will not only solve the problem I described but possibly reduce the cost to analyze the error/notice messages in the frontend programs. Adding new field can be possible without breaking current version of Frontend/Backend protocol since the protocol is extensible in this area: "Since more field types might be added in future, frontends should silently ignore fields of unrecognized type."(from "46.5. Message Formats" of PostgreSQL 9.2 documentation) BTW, changing existing "S" field not to be localized would work but I'm afraid it breaks backward compatibility. Comments? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp
Tatsuo Ishii <ishii@postgresql.org> writes: > I described the problem with possibly localized "S" filed of > ErrorResponse(and NoticeResponse) in Frontend/Backend protocol. > http://archives.postgresql.org/pgsql-hackers/2012-05/msg00912.php > So I would like to propose a solution for this (for 9.3): add new > field to ErrorResponse and NoticeResponse. The new field will have the > same value as "S" except that it's never localized. This will not only > solve the problem I described but possibly reduce the cost to analyze > the error/notice messages in the frontend programs. 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?) 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. 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. > BTW, changing existing "S" field not to be localized would work but > I'm afraid it breaks backward compatibility. We made it localized intentionally, on the grounds that its principal and probably sole use was for presentation to human users. I've not heard previous complaints about that decision. regards, tom lane
> 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