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

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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Bruce Momjian <bruce(at)momjian(dot)us>, fgp(at)phlo(dot)org, Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Error code for "terminating connection due to conflict with recovery"
Date: 2011-02-01 01:27:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Jan 31, 2011 at 7:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Jan 31, 2011 at 7:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I agree, 28 is a completely off-point category.  But it wasn't in 40
>>> before, either --- we are talking about where it currently says
>>> ADMIN_SHUTDOWN, no?  I'd vote for keeping it in class 57 (operator
>>> intervention), as that is both sensible and a minimal change from
>>> current behavior.
>> Seems a little weird to me, since the administrator hasn't done
>> anything.
> Sure he has: he issued the DROP DATABASE command that's causing the
> system to disconnect standby sessions.

Well, I'm not sure how much this matters - as long as it's a dedicated
error code, the user can write code to DTRT somehow.  But I don't buy
your argument.  Ultimately, user activity causes any kind of recovery
conflict.  So I don't see why one particular kind of recovery conflict
should be in a different class than all the others.  It's the
administrator (I guess) who ran VACUUM FREEZE and blew up every query
running on the standby, too.  But the user doesn't directly control
when recovery conflicts get fired on the standby - it's the system
that decides to do that.  Right now, we happen to ignore
max_standby_delay for drop database, but in general the coupling
between when an action happens on the master and when conflicts occur
on the standby is fairly loose.

Then again - in theory, there's no reason why we couldn't drop a
database on the master when it's in use, kicking out everyone using it
with this very same error code.  We don't happen to handle it that way
right now, but...

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2011-02-01 01:52:04
Subject: Re: Error code for "terminating connection due to conflict with recovery"
Previous:From: Bruce MomjianDate: 2011-02-01 01:25:59
Subject: Re: pg_upgrade fails for non-postgres user

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