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

> Actually, it was Simon and Florian who were arguing that we needed to
> distinguish these cases from other types of recovery conflict;
> Tatsuo-san was arguing that we needed to distinguish a
> dropped-database-recovery-conflict from a cluster shutdown - the
> current choice of ERRCODE_ADMIN_SHUTDOWN makes that confusing.
> 
> ISTM we can invent zero, one, or two new error codes here.  If we
> invent zero, then we change all recovery conflicts to look like
> serialization failures and call it good.  If we invent one, then we
> make retryable recovery conflicts look like serialization failures and
> the dropped-database case gets a newly minted error code that means
> just that.  Or we can invent two, and make serialization failures
> different from recovery conflicts, and retryable recovery conflicts
> different from the dropped-database variety.
> 
> I don't have a terribly strong opinion as between those options.

As a novice I am not sure why we _wouldn't_ create two new separate
error codes --- it not not like they cost us anything, and they
certainly sound distinct.  The requirement to retry is clearly something
we want to avoid if we get a new error code.

Backpatching to 9.0 makes sense too, though the problem is the delay in
getting the code into a released minor version.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +