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

On Sun, Jan 30, 2011 at 9:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sun, Jan 30, 2011 at 8:42 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> BTW, so far as this goes:
>>> http://archives.postgresql.org/pgsql-hackers/2011-01/msg01152.php
>>> we should certainly *not* have the same text for two different
>>> SQLSTATEs.  If it's worth distinguishing two cases then it's worth
>>> providing different texts that make it clear what the cases are.
>
>> Well, then we either need to change the error codes to be the same, or
>> the texts to be different.
>
>> The only case in which we emit ERRCODE_ADMIN_SHUTDOWN is when the
>> database gets dropped out from underneath the HS backend.  I don't
>> think it's worth having a separate path just to handle that case; if
>> the user retries the operation it should quickly become clear that the
>> database is gone.
>
> Somone, Tatsuo-san IIRC, was saying that pgpool would really like to
> know the difference so that it doesn't have to retry at all.  I'm not
> sure how useful that really is, but that's the argument for having a
> distinct SQLSTATE.  If we do believe that that's useful, I think it
> should be a unique new SQLSTATE that never means anything other than
> "your database got deleted from under you".  Piggybacking that meaning
> on an existing SQLSTATE definitely seems completely bogus to me.

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company