Re: SQLSTATE for Hot Standby cancellation
От | Simon Riggs |
---|---|
Тема | Re: SQLSTATE for Hot Standby cancellation |
Дата | |
Msg-id | 1273222261.12659.1314.camel@ebony обсуждение исходный текст |
Ответ на | SQLSTATE for Hot Standby cancellation (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: