Re: Transaction aborts on syntax error.

From: "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>
To: <simon(at)2ndquadrant(dot)com>, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Andrej Czapszys" <czapszys(at)comcast(dot)net>, "Gavin Sherry" <swm(at)linuxworld(dot)com(dot)au>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Transaction aborts on syntax error.
Date: 2004-02-13 13:36:50
Message-ID: 46C15C39FEB2C44BA555E356FBCD6FA49620B2@m0114.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> 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
> violations and many other system errors aren't retryable. In the example

You seem to ignore the fact, that a lot of errors (and I assume most of
the real world cases, where the appl actually reacts inside a transaction) are
"repared" by these applications by doing something else instead.

Like the application does an insert gets a duplicate key error and does an update
instead. Or it does an insert gets a foreign key constraint violation,
populates the foreign table and does the insert again. Note that this programming
practice is more efficient, than letting the appl check beforehand if the error cases
are seldom.

It seems to me, that leaving all this to the client (which implicitly inserts
savepoints) can never be as efficient as a serverside feature.

Andreas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rod Taylor 2004-02-13 13:57:20 Re: 7.4 - FK constraint performance
Previous Message Andrew Dunstan 2004-02-13 11:59:38 Re: [PATCHES] log session end - again