On Wed, Jul 11, 2007 at 06:09:55PM -0400, Tom Lane wrote: > This is really pretty silly to be getting worked up about. The command > in question wouldn't have been allowed at all except to a superuser, > and there are plenty of ways to catastrophically destroy your database > when you are superuser; most of which we will never consider blocking
I think the problem is it is nowise obvious that LOCK [sometable]; PREPARE TRANSACTION is, as superuser, dangerous in the way that DROP CASCADE is. Or rm -rf, for that matter. It seems to me that at the very least, some pretty extensive documentation of the perils of running 2PC as a superuser ought to be available, and if it's there, it didn't leap out at me. But the other problem I see here is that the solution hits more than just the problematic state. If we have bad pages on disk, for instance, we zero pages; we don't drop the table. Similarly, it seems that all that's necessary here is an external tool to grovel through the prepared transaction files and somehow figure out what locks, if any, they entail. Wouldn't that be enough to then allow you to shoot the relevant file, thereby losing only that prepared transaction instead of all of them? (I'm not suggesting that no data must ever be lost in this case; just that we should lose the minimum necessary to make the system work.) A -- Andrew Sullivan | [EMAIL PROTECTED] A certain description of men are for getting out of debt, yet are against all taxes for raising money to pay it off. --Alexander Hamilton ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate