"Simon Riggs" <simon@2ndquadrant.com> writes:
> I'd be much more comfortable if LOCK TABLE caused a message to the log
> if it is executed on any system table.
Enabled by "set training_wheels = on", perhaps?
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
for the same reasons that Unix systems have never tried to block root
from doing "rm -rf /". I'd say the real design flaw in Peter's
referenced application is that they're running it as superuser.
> There seems like a number of ways that unresolved prepared transactions
> can cause problems. We really need to have startup mention how many
> prepared transactions there are, so we have some chance of understanding
> and resolving potential problems.
While I have no particular objection to such a log entry, I doubt it
will fix anything; how many people will really think to look in the
postmaster log? In any case, most of the problems I've personally run
into with prepared xacts have nothing to do with crashes and so nothing
like that would ever get emitted. (The typical way I get bitten is to
interrupt the regression tests because I changed my mind about
something, and manage to do this just while the prepared_xacts test has
some open prepared xacts.)
regards, tom lane
