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

On Fri, Jan 14, 2011 at 12:29 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> This whole thing is confused. No change is appropriate here at all.
>
> We issue ERRCODE_T_R_SERIALIZATION_FAILURE almost all of the time for
> recovery conflicts.
>
> We issue ERRCODE_ADMIN_SHUTDOWN only if the conflict is non-retryable,
> which occurs if someone drops the database that the user was connected
> to when they get kicked off. That code exists specifically to inform the
> user that they *cannot* reconnect. So pgpool should not be trying to
> trap that error and reconnect.

CheckRecoveryConflictDeadlock() uses ERRCODE_QUERY_CANCELLED.
ProcessInterrupts() sometimes uses ERRCODE_T_R_SERIALIZATION_FAILURE
and sometimes uses ERRCODE_ADMIN_SHUTDOWN.  It seems to me that it
wouldn't be a bad thing to be a bit more consistent, and perhaps to
have dedicated error codes for recovery conflicts.  This bit strikes
me as particularly strange:
               else if (RecoveryConflictPending && RecoveryConflictRetryable)               {
pgstat_report_recovery_conflict(RecoveryConflictReason);                      ereport(FATAL,
 

(errcode(ERRCODE_T_R_SERIALIZATION_FAILURE),                         errmsg("terminating connection due to
conflict with recovery"),                                        errdetail_recovery_conflict()));               }
       else if (RecoveryConflictPending)               {
pgstat_report_recovery_conflict(RecoveryConflictReason);                      ereport(FATAL,
          (errcode(ERRCODE_ADMIN_SHUTDOWN),                         errmsg("terminating connection due to
 
conflict with recovery"),                                        errdetail_recovery_conflict()));               }

That's the same error message at the same severity level with two
different SQLSTATEs depending on RecoveryConflictRetryable.  Seems a
bit cryptic.

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