> 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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
