Skip site navigation (1) Skip section navigation (2)

Re: SQLSTATE for Hot Standby cancellation

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Yeb Havinga <yebhavinga(at)gmail(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Greg Smith <greg(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SQLSTATE for Hot Standby cancellation
Date: 2010-05-07 08:51:01
Message-ID: 1273222261.12659.1314.camel@ebony (view raw or flat)
Thread:
Lists: 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

Attachment: hs_cancel_errcode.patch
Description: text/x-patch (1.2 KB)

In response to

pgsql-hackers by date

Next:From: Mike FowlerDate: 2010-05-07 09:46:55
Subject: Re: Adding xpath_exists function
Previous:From: Nikhil SontakkeDate: 2010-05-07 06:14:26
Subject: Re: possible memory leak with SRFs

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group