From: | Rod Taylor <rbt(at)rbt(dot)ca> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Andrew Sullivan <andrew(at)libertyrms(dot)info>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 2-phase commit |
Date: | 2003-09-29 18:32:27 |
Message-ID: | 1064860346.61134.85.camel@jester |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > It seems that one way out is just to fall back to "read only" as soon
> > as a single failure happens. That's the least graceful but maybe
> > safest approach to failure, analogous to what fsck does to your root
> > filesystem at boot time. Of course, since there's no "read only"
> > mode at the moment, this is all pretty hand-wavy on my part :-/
>
> Yes, but that affects all users, not just the transaction we were
> working on. I think we have to get beyond the idea that this can be made
> failure-proof, and just outline the behaviors for failure, and it has to
> be configurable by the administrator.
Yes, but holding locks on the affected rows IS appropriate until the
administrator issues something like:
ALTER SYSTEM ABORT GLOBAL TRANSACTION 123;
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-09-29 18:36:28 | Re: Alter Table Column Datatype |
Previous Message | Greg Stark | 2003-09-29 18:25:02 | Re: Alter Table Column Datatype |