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@crankycanuck.ca
> 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/
>
