On Thu, 2010-05-06 at 15:00 +0100, Simon Riggs wrote: > On Thu, 2010-05-06 at 12:08 +0200, Yeb Havinga wrote: > > > That's funny because when I was reading this thread, I was thinking the > > exact opposite: having max_standby_delay always set to 0 so I know the > > standby server is as up-to-date as possible. The application that > > accesses the hot standby has to be 'special' anyway because it might > > deliver not-up-to-date data. If that information about specialties > > regarding querying the standby server includes the warning that queries > > might get cancelled, they can opt for a retry themselves (is there a > > special return code to catch that case? like PGRES_RETRY_LATER) or a > > message to the user that their report is currently unavailable and they > > should retry in a few minutes. > > Very sensible. Kevin Grittner already asked for that and I alread > agreed, yet it has not been implemented that way > http://archives.postgresql.org/pgsql-hackers/2008-12/msg01691.php > > Can anyone remember a specific objection to that 'cos it still sounds > very sensible to me and is a quick, low impact change. > > Currently the SQLSTATE is ERRCODE_ADMIN_SHUTDOWN or > ERRCODE_QUERY_CANCELED if not idle. That makes it even harder to > determine the retryability, since it can come back in one of two states. > > Proposed SQLSTATE for HS cancellation is > case PROCSIG_RECOVERY_CONFLICT_BUFFERPIN: > case PROCSIG_RECOVERY_CONFLICT_LOCK: > case PROCSIG_RECOVERY_CONFLICT_SNAPSHOT: > case PROCSIG_RECOVERY_CONFLICT_STARTUP_DEADLOCK: > recovery_conflict_errcode = ERRCODE_T_R_SERIALIZATION_FAILURE; > break; > case PROCSIG_RECOVERY_CONFLICT_DATABASE: > case PROCSIG_RECOVERY_CONFLICT_TABLESPACE: > recovery_conflict_errcode = ERRCODE_ADMIN_SHUTDOWN; > break; > > We don't have a retryable SQLSTATE, so perhaps we should document that > serialization_failure and deadlock_detected are both retryable error > conditions. As the above implies HS can throw some errors that are > non-retyable, so we use ERRCODE_ADMIN_SHUTDOWN.
Implemented as ERRCODE_ADMIN_SHUTDOWN only in the case of a dropped database. ERRCODE_T_R_SERIALIZATION_FAILURE in other cases. -- Simon Riggs www.2ndQuadrant.com
*** a/src/backend/tcop/postgres.c --- b/src/backend/tcop/postgres.c *************** *** 2936,2949 **** ProcessInterrupts(void) DisableCatchupInterrupt(); if (DoingCommandRead) ereport(FATAL, ! (errcode(ERRCODE_ADMIN_SHUTDOWN), errmsg("terminating connection due to conflict with recovery"), errdetail_recovery_conflict(), errhint("In a moment you should be able to reconnect to the" " database and repeat your command."))); else ereport(ERROR, ! (errcode(ERRCODE_QUERY_CANCELED), errmsg("canceling statement due to conflict with recovery"), errdetail_recovery_conflict())); } --- 2936,2949 ---- DisableCatchupInterrupt(); if (DoingCommandRead) ereport(FATAL, ! (errcode(ERRCODE_T_R_SERIALIZATION_FAILURE), errmsg("terminating connection due to conflict with recovery"), errdetail_recovery_conflict(), errhint("In a moment you should be able to reconnect to the" " database and repeat your command."))); else ereport(ERROR, ! (errcode(ERRCODE_T_R_SERIALIZATION_FAILURE), errmsg("canceling statement due to conflict with recovery"), errdetail_recovery_conflict())); }
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers