Hello,
I have a much clearer picture of the issue. So, does this mean that
with nested transactions, all statements will execute within a
mini-transaction, which may be executed within a branch of user
defined sub-transactions. Such that:
begin
...
...
begin
...
...
mini-tr
Rod Taylor wrote:
> > > > BEGIN WORK;
> > > > LOCK oldtab;
> > > > CREATE_X TABLE newtab AS SELECT * FROM oldtab;
> > > > DELETE oldtab;
> > > > COMMIT
> > > >
> > > > In this case, you would want the database to abort on a syntax error, right?
> > >
> > >
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Imagine this:
>
> BEGIN WORK;
> LOCK oldtab;
> CREATE_X TABLE newtab AS SELECT * FROM oldtab;
> DELETE oldtab;
> COMMIT
>
> In this case, you would want the database to abort on a syntax error, right?
Certainly not if I
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Josh Berkus wrote:
>> Hmmm I'm not sure how you arrived at this wording for the TODO. How are
>> we defining a "syntax error"?
>
> Parser error, I would say. Misspelling a table name, perhaps.
FWIW, a misspelled table name is plainly a semantic e
Can we clarify what is meant by the client? It is my
expectation/desire that the client library would handle this as a
setting similar to "AutoCommit", which would implicitly protect each
statement within a nested block (savepoint), causing only itself to
abort. Such as, "OnError=>[abort|continue
> Oh, yea, that would be bad. So you want to invalidate the entire
> session on any error? That could be done.
>
> --
> Bruce Momjian| http://candle.pha.pa.us
> [EMAIL PROTECTED] | (610) 359-1001
Well, that's exactly the current behaviour, which crea
Josh Berkus wrote:
> Bruce,
>
> > > So, whatever "error handling mode" conveniences we wish to put in should
> > > be put in on the client side.
> >
> > Added to TODO:
> >
> > * Use nested transactions to prevent syntax errors from aborting
> > ?a transaction
>
> Hmmm I'm
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>> which might not be for every statement. Savepoints that you don't
>> actually need are going to be a fairly expensive overhead, AFAICS.
> Well with other db's per statement rollback is a no overhead feature,
> so this is pg specific.
I
Bruce,
> > So, whatever "error handling mode" conveniences we wish to put in should
> > be put in on the client side.
>
> Added to TODO:
>
> * Use nested transactions to prevent syntax errors from aborting
> a transaction
Hmmm I'm not sure how you arrived at this wording
> > It seems to me, that leaving all this to the client (which implicitly
> > inserts savepoints) can never be as efficient as a serverside feature.
>
> I think this is an overly narrow view of "efficiency". With client
> control, the client can insert savepoints whereever it needs them,
Yes, b
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> It seems to me, that leaving all this to the client (which implicitly
> inserts savepoints) can never be as efficient as a serverside feature.
I think this is an overly narrow view of "efficiency". With client
control, the client can inser
> In both cases, the transaction either commits or rollback occurs. No
> other option is possible at the end of the transaction, but in the first
> style of transaction semantics you get a "mid-way" decision point. This
> only refers to retryable errors, since errors like access rights
> violation
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Rod Taylor wrote:
> >> Can this be done entirely on the client side?
> >>
> >> Have psql silently wrap every statement going out with a BEGIN and a
> >> COMMIT or ROLLBACK depending on whether there was an error or not?
>
> > Yep, we
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Rod Taylor wrote:
>> Can this be done entirely on the client side?
>>
>> Have psql silently wrap every statement going out with a BEGIN and a
>> COMMIT or ROLLBACK depending on whether there was an error or not?
> Yep, we could do it in the client like
>Bruce Momjian
> Simon Riggs wrote:
> > >Tom Lane
> > > "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > > > Most importantly, other references I have state that: the ANSI
> > SQL-99
> > > > specification does require that if a statement errors then only
that
> > > > statement's changes are rolled bac
>>
In this case, you would want the database to abort on a syntax error, right?
>>
Am I completely off thread to ask why HOW we allow an abort on syntax
errors? (at least in regard to stored functions)
Shouldn't PostgreSQL do somethng intellignet like *notice* the syntax
error in the stored funct
>Bruce Momjian wrote
> Zeugswetter Andreas SB SD wrote:
> >
> > >> Improving on "not ideal" would be good, and would get even closer
to
> > >> full Oracle/SQLServer migration/compatibility. However, since
I've
> never
> > >> looked at that section of code, I couldn't comment on any
particular
> >
> > > BEGIN WORK;
> > > LOCK oldtab;
> > > CREATE_X TABLE newtab AS SELECT * FROM oldtab;
> > > DELETE oldtab;
> > > COMMIT
> > >
> > > In this case, you would want the database to abort on a syntax error, right?
> >
> > Certainly not if I was typing this from the command line. Imagine
Greg Stark wrote:
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > Imagine this:
> >
> > BEGIN WORK;
> > LOCK oldtab;
> > CREATE_X TABLE newtab AS SELECT * FROM oldtab;
> > DELETE oldtab;
> > COMMIT
> >
> > In this case, you would want the database to abort on a syntax er
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> It does require that the application be meticulous in its checking though.
> Existing client programs, for instance, may ignore any errors coming back
> from PQexec() during the transaction and just see if the COMMIT succeeds.
> Such could would b
Zeugswetter Andreas SB SD wrote:
>
> >> Improving on "not ideal" would be good, and would get even closer to
> >> full Oracle/SQLServer migration/compatibility. However, since I've never
> >> looked at that section of code, I couldn't comment on any particular
> >> approach nor implement such a ch
On Thu, Feb 12, 2004 at 09:55:36AM +0100, Zeugswetter Andreas SB SD wrote:
>
> Yeah, but in other db's this is solved by the frontend. e.g. in Informix
> dbaccess has a mode that simply stops execution upon first error. So I don't
> think this is a nogo argument, if we added such a feature to psq
>> Improving on "not ideal" would be good, and would get even closer to
>> full Oracle/SQLServer migration/compatibility. However, since I've never
>> looked at that section of code, I couldn't comment on any particular
>> approach nor implement such a change, so I'll shut up and be patient.
>
> I
Simon Riggs wrote:
> I've have tried to work out which section of the manual to document this
> in. The most likely section would seem to be: doc/src/sgml/mvcc.sgml,
> which is the Concurrency Control chapter of the User's Guide (on PDF).
> I'd suggest including an extra sect1 section like this...e
Simon Riggs wrote:
> >Tom Lane
> > "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > > Most importantly, other references I have state that: the ANSI
> SQL-99
> > > specification does require that if a statement errors then only that
> > > statement's changes are rolled back.
>
> > > ...if anybody has
>Tom Lane
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > Most importantly, other references I have state that: the ANSI
SQL-99
> > specification does require that if a statement errors then only that
> > statement's changes are rolled back.
> > ...if anybody has a copy of the actual spec could th
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Most importantly, other references I have state that: the ANSI SQL-99
> specification does require that if a statement errors then only that
> statement's changes are rolled back.
No. The spec says
The execution of a may be initiated implicit
>Andrej Czapszys
> This is a major bug which greatly diminishes the confidence of my
> co-workers in postgresql.
This is NOT a bug. Transactional robustness is important and PostgreSQL
has a very strict implementation in this area.
>Greg Stark
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Edw
Gavin Sherry wrote:
Its not that there's a rationale behind it. Rather, the existing error
handling code *has* to abort the current transaction because an error has
taken place. In a multi statement transaction block (ie, BEGIN; ...; ...;
... COMMIT;) each statement piggy backs on onto the whole
Greg Stark <[EMAIL PROTECTED]> writes:
> So you picture the backend automatically introducing a mini-nested-transaction
> for every request and automatically rolling that back on any error. So the
> application or user wouldn't have to do anything to continue processing
> ignoring the error?
You'r
Tom Lane <[EMAIL PROTECTED]> writes:
> What it comes down to is that a lot of code in the backend assumes that
> transaction abort can be relied on to do any post-elog cleanup needed,
> such as releasing locks or reclaiming leaked memory. I don't think we
> can afford to give up that assumption;
Greg Stark <[EMAIL PROTECTED]> writes:
> But why does the database enforce that every syntax error *requires* a
> transaction roll back?
PG enforces that every error requires a transaction abort. Period, full
stop. Picking and choosing which errors might not really require a
rollback involves a
On Mon, 8 Feb 2004, Greg Stark wrote:
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > Edwin S. Ramirez wrote:
> > > Hello,
> > >
> > > Is is possible to change the transaction behaviour not to abort when a
> > > syntax error occurs.
> > >
> > > I've done some searches on the list, and have not
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Edwin S. Ramirez wrote:
> > Hello,
> >
> > Is is possible to change the transaction behaviour not to abort when a
> > syntax error occurs.
> >
> > I've done some searches on the list, and have not found anything.
>
> No, we need nested transactions f
Edwin S. Ramirez wrote:
> Hello,
>
> Is is possible to change the transaction behaviour not to abort when a
> syntax error occurs.
>
> I've done some searches on the list, and have not found anything.
No, we need nested transactions for that. We are working on it or at
least have a plan.
--
On Fri, Jan 30, 2004 at 07:43:06AM -0800, Edwin S. Ramirez wrote:
> Is is possible to change the transaction behaviour not to abort when a
> syntax error occurs.
Not currently.
--
Alvaro Herrera ()
"And as an added bonus, now my computer goes to the toilet for me, leaving me
free to spend time
36 matches
Mail list logo
