On Fri, Jan 14, 2011 at 12:29 PM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers