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

Re: Error code for "terminating connection due to conflict with recovery"

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, simon(at)2ndquadrant(dot)com, fgp(at)phlo(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Error code for "terminating connection due to conflict with recovery"
Date: 2011-01-31 14:46:59
Message-ID: 201101311446.p0VEkxl19501@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
> Actually, it was Simon and Florian who were arguing that we needed to
> distinguish these cases from other types of recovery conflict;
> Tatsuo-san was arguing that we needed to distinguish a
> dropped-database-recovery-conflict from a cluster shutdown - the
> current choice of ERRCODE_ADMIN_SHUTDOWN makes that confusing.
> 
> ISTM we can invent zero, one, or two new error codes here.  If we
> invent zero, then we change all recovery conflicts to look like
> serialization failures and call it good.  If we invent one, then we
> make retryable recovery conflicts look like serialization failures and
> the dropped-database case gets a newly minted error code that means
> just that.  Or we can invent two, and make serialization failures
> different from recovery conflicts, and retryable recovery conflicts
> different from the dropped-database variety.
> 
> I don't have a terribly strong opinion as between those options.

As a novice I am not sure why we _wouldn't_ create two new separate
error codes --- it not not like they cost us anything, and they
certainly sound distinct.  The requirement to retry is clearly something
we want to avoid if we get a new error code.

Backpatching to 9.0 makes sense too, though the problem is the delay in
getting the code into a released minor version.

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

In response to

Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2011-01-31 14:52:27
Subject: Re: Spread checkpoint sync
Previous:From: Robert HaasDate: 2011-01-31 14:44:58
Subject: Re: Spread checkpoint sync

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