Robert Haas <robertmh...@gmail.com> writes: > On Mon, Jan 31, 2011 at 7:25 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Robert Haas <robertmh...@gmail.com> writes: >>> 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. Well, yeah, but the predictability of the failure is pretty variable. In this case we can say that the error definitely would not have occurred if somebody hadn't done a DROP DATABASE on the master while there were live sessions in that DB on the slave. I think that's a sufficiently close coupling to say that the error is the result of an operator action. OTOH, the occurrence of deadlocks is (usually) a lot more dependent on random-chance timing of different transactions, and you usually can't point to any action that intentionally caused a deadlock. > 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... Yeah, that was in the back of my mind too. "DROP DATABASE foo FORCE", maybe? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers