From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Jaime Casanova" <systemguards(at)gmail(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: savepoint improvements |
Date: | 2007-01-22 15:02:35 |
Message-ID: | 1169478155.3776.304.camel@silverbirch.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2007-01-22 at 09:25 -0500, Merlin Moncure wrote:
> On 1/21/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > "Jaime Casanova" <systemguards(at)gmail(dot)com> writes:
> > > On 1/21/07, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> > >> - continue on error i.e. COMMIT can/might succeed - though there are
> > >> still cases where it cannot, such as a serializable exception.
> >
> > > and what should be the behaviour of that? the same as rollback?
> >
> > The only conceivable implementation is an implicit savepoint issued
> > before each statement.
>
> I'm not sure I agree here...before the NT implementation was changed
> over to savepoint syntax it was perfectly possible to recover from
> errors inside a transaction...and is still possible in plpgsql
> functions only. What I'm asking for is to reopen this behavior
> somehow...in the production environments I've worked in application
> update and maintenance relied heavily on scripting, and lack of this
> functionality forces me to wrap the script launch with C code to work
> around limitations of the savepoint system.
Could you post an example, just so we're all clear what the problems
are? I thought I understood what you are requesting; I may not.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2007-01-22 15:30:09 | Re: [HACKERS] Autovacuum Improvements |
Previous Message | Heikki Linnakangas | 2007-01-22 14:51:47 | Piggybacking vacuum I/O |