Good point, but just to be clear, I was asking about 2PC because our app
writes to two different databases, and the authors never considered that
the second commit might fail.
On Mon, 23 Jul 2007, Andrew Sullivan wrote:
On Fri, Jul 20, 2007 at 05:17:00PM -0700, Jeff Davis wrote:
On Fri, 2007-07-20 at 15:26 -0400, Andrew Sullivan wrote:
instance, recently it turned out that there was a way, using 2PC, to
lock everybody out of the database. The only remedy to that at the
moment is to blow away all the PREPAREd transactions, which could
mean you lose something that was already committed to.
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00245.php
which can only be done as superuser locking a system table.
I would classify that as a "catastrophic" problem, since it involves
manually modifying $PGDATA.
Right. But there's a big difference between this case and many
catastrophic problems, because it's entirely possible that the whole
reason you were using 2PC was to increase reliability in the face of
various disasters, including operator error. So you had _better_
know which operator errors of this very feature are likely to cause
catastrophes.
A
--
Andrew Sullivan | ajs@xxxxxxxxxxxxxxx
The fact that technology doesn't work is no bar to success in the marketplace.
--Philip Greenspun
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
