Re: Error code for "terminating connection due to conflict with recovery"

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Jan 30, 2011 at 8:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I'm inclined to agree that 9.0 is new enough that changing this
>> shouldn't be too traumatic. If we leave it till 9.1 there will
>> probably be more pain not less.

> But if you and Tatsuo-san are both in favor of it, then perhaps we
> should do it. However, that might require people to write application
> code which has to be aware of which minor version it's talking to,
> which is usually something we try hard to avoid.

Well, the thing is that if we delay changing this until 9.1, then pretty
much every app that cares about this will have to be prepared to deal
with both possibilities, and will thus have to contain some
version-sensitive code, and will have to keep dealing with that for the
support lifetime of 9.0.x. My thought is that if it changes in 9.0.4,
client authors will probably be able to say "we support >= 9.0.4" and
just deal with one behavior. 9.0 hasn't yet had so much uptake that
this is an infeasible position, especially given the rate at which we're
still finding serious bugs in it. 9.0.early isn't going to be getting
run by the sorts of DBAs who would care about apps that care about this.

IOW, I think we can still consider changing error codes that are new in
9.0.x as a bug fix.

> Any opinion on what to do about the one that's returning ERRCODE_ADMIN_SHUTDOWN?

Pretty much the same argument here, I think: if we are going to change
the SQLSTATE we should do it now not later. However, I think Simon
was actually arguing to not change this one either now or later, and
that might also be a defensible position.

BTW, so far as this goes:
http://archives.postgresql.org/pgsql-hackers/2011-01/msg01152.php
we should certainly *not* have the same text for two different
SQLSTATEs. If it's worth distinguishing two cases then it's worth
providing different texts that make it clear what the cases are.

regards, tom lane