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

On Fri, Jan 14, 2011 at 12:29 PM, Simon Riggs <simon(at)2ndquadrant(dot)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