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

Reply via email to