> 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. +
