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