On Mon, 2011-01-31 at 16:24 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On Mon, 2011-01-31 at 14:58 -0500, Tom Lane wrote:
> >> The trouble with ERRCODE_ADMIN_SHUTDOWN is that it might lead a
> >> connection pooler to expect that *all* its connections are going bad,
> >> not just the ones that are connected to a specific database. I think
> >> this is a bad decision. Programs that are interested in testing for this
> >> case at all are likely to need to be worried about that distinction.
>
> > That's a reasonable argument.
>
> > My objection to a new code is only to one that is so specific that
> > people have to program for ERRCODE_BLUE_MOON_ON_A_LEAP_YEAR.
>
> What's wrong with ERRCODE_DATABASE_DROPPED, or something like that?
>
> > Can we invent a new "catch-all" that might be used here? Something that
> > means "unknown operational error, not sure what to do".
>
> Because that's not the situation here. We know exactly what a pooler
> should do. It might be an infrequent case, but obscurantism isn't going
> to help anyone.
OK, that makes sense to me.
I would make ERRCODE_DATABASE_DROPPED an Invalid Authorization error,
rather than a Transaction Rollback code. So sqlstate 28P02
The sensible handling of such an error is not to retry, or at least to
switch to an alternate if one is available.
Ready to commit if no objection.
-- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services