Re: Proposal: add new field to ErrorResponse and NoticeResponse

> 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