Holger Jakobs wrote:
Calling a procedure is a statement as well, and it includes all other
procedures called from this procedure. So the statement level is always
the statements that were carried out directly in the transaction. If
anything within one statement fails, the statement was not carried
On 11 Nov, Jan Wieck wrote:
> As long as we talk in an SQL context, can you please stick to SQL
> terms? I don't know exactly what you mean with "operation". If for
> example the statement
>
> DELETE FROM order_line WHERE ol_ordernum = 4711;
>
> has 12 matching rows in order_line, is an op
>
> Why is that "funny behaviour" for you? By putting the statements into
> a transaction block you told the data management system "I want this
> group of statements to be atomic". Atomic means all or nothing. It
> might not be exactly what you intended to say, and you have a point
> if you concl
Holger Jakobs wrote:
Why is that "funny behaviour" for you? By putting the statements into
a transaction block you told the data management system "I want this
group of statements to be atomic". Atomic means all or nothing. It
might not be exactly what you intended to say, and you have a point
if
> Although i am not aware of the roots of this discussion but would like
> to
> comment at this point .
>
> When we work with sequences an aborted transaction does have
> a permanent effect on the last value of sequence. Is this behaviour
> not a violation of above defination of transaction ?
I
Rod Taylor wrote:
be recovered either. When committing a transaction the effects of all
operations that did not fail will be made permanent. This is how
transaction processing is described in the literature.
I would be interested in reading that (URLs please) as I didn't see
> be recovered either. When committing a transaction the effects of all
> operations that did not fail will be made permanent. This is how
> transaction processing is described in the literature.
I would be interested in reading that (URLs please) as I didn't see
anything in the spec that was inte
Holger Jakobs wrote:
Hi Stephan,
On 9 Nov, Stephan Szabo wrote:
On Fri, 7 Nov 2003 [EMAIL PROTECTED] wrote:
Whenever an error occurs within the transaction, PostgreSQL puts the
whole transaction in an *ABORT* state, so that there is no difference
at all between COMMITing or ROLLBACKing it. Even
Hi Stephan,
On 9 Nov, Stephan Szabo wrote:
> On Fri, 7 Nov 2003 [EMAIL PROTECTED] wrote:
>
>> Whenever an error occurs within the transaction, PostgreSQL puts the
>> whole transaction in an *ABORT* state, so that there is no difference
>> at all between COMMITing or ROLLBACKing it. Even commands
On Mon, 10 Nov 2003, Holger Jakobs wrote:
> Hi Stephan,
>
> On 9 Nov, Stephan Szabo wrote:
> > On Fri, 7 Nov 2003 [EMAIL PROTECTED] wrote:
> >
> >> Whenever an error occurs within the transaction, PostgreSQL puts the
> >> whole transaction in an *ABORT* state, so that there is no difference
> >>
On Fri, 7 Nov 2003 [EMAIL PROTECTED] wrote:
> Whenever an error occurs within the transaction, PostgreSQL puts the
> whole transaction in an *ABORT* state, so that there is no difference at
> all between COMMITing or ROLLBACKing it. Even commands successfully
> carried out before the error ocurred
Dear PostgreSQL Gurus,
I have been using PostgreSQL for quite a while and always relied on its
handling of transaction and concurrency. But recently I discovered a
behaviour that deviates quite a lot from how I understand transactions
and how things are handled by other databases: HP Allbase, Orac
12 matches
Mail list logo
