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

On Mon, 2011-01-31 at 09:46 -0500, Bruce Momjian wrote:
> > 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.

It's the way it was because of discussion during 9.0.
The errors for "serialization error" and "deadlock" are appropriate
because everybody knows these exist. If you invent a new error code then
you'll need to re-program loads of applications which would all "just
work" if we use those error codes. Kevin specifically requested it for
that reason.

That leaves the error code for the drop database case. As both Tatsuo
and myself have said, it needs to be different so we do not retry it. I
don't personally think an edge case like that needs a whole new error
code to explain it.

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

I treat this as a bugfix, so backpatch is appropriate. My earlier "fix"
in 9.0 beta didn't cover the case pointed out by Robert/Florian and as
Tatsuo points out, we need to have a retryable error for all common
cases.

--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services