Re: SQLSTATE for Hot Standby cancellation

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