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

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
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company