On Thu, Apr 29, 2004 at 10:31:07PM -0400, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > > > Yeah. We agreed in principle awhile back to "fix" this on the backend
> > > > side by postponing the actual transaction start until the first command
> > > > after BEGIN. I looked at this just before 7.4 feature freeze, but
> > > > decided it wasn't quite trivial and I hadn't time to make it happen.
> > > > No one's gone back to work on it during the 7.5 cycle either.
> > > >
> > > > Right now I'm not wanting to touch that code since both Alvaro and the
> > > > 2PC guy have open patches against it...
> >
> > Actually, my patch is waiting for you to review it ;-) On the other
> > hand, since I'm already touching that code, maybe I can include it in my
> > patch. Or would you prefer to keep those things separate?
>
> Alvaro, can I ask what is left?
Several things. I think I wrote them along with my previous patch. The
visibility rules and the pg_clog protocol are what comes to mind
immediately. This is the difficult part.
> I know you have pg_subtrans, but what plans do you have to abort
> subtransactions and bring the system back to the state before the
> subtransaction started?
Some of those things are already in place. For example cursors are
closed/dropped, file deletions (DROP TABLE) no longer take place, file
creation is reverted, and the server is in a known state. Some things
are missing: how to deal with deferred triggers, prepared statements,
locks, on-commit actions.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Vivir y dejar de vivir son soluciones imaginarias.
La existencia está en otra parte" (Andre Breton)
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
