From: | Bill Moran <wmoran(at)potentialtech(dot)com> |
---|---|
To: | "Phoenix Kiula" <phoenix(dot)kiula(at)gmail(dot)com> |
Cc: | "Gregory Stark" <stark(at)enterprisedb(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Moving to postgresql and some ignorant questions |
Date: | 2007-08-14 17:56:51 |
Message-ID: | 20070814135651.1fd56abe.wmoran@potentialtech.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
In response to "Phoenix Kiula" <phoenix(dot)kiula(at)gmail(dot)com>:
> > If you issue a BEGIN then nothing gets committed until you issue a COMMIT. If
> > anything happens in the meantime then everything you've done since the BEGIN
> > disappears.
>
> There are some cases where I would like to bunch queries into a
> transaction purely for speed purposes, but they're not interdependent
> for integrity. E.g.,
>
> BEGIN TRANSACTION;
> UPDATE1;
> UPDATE2;
> UPDATE3;
> COMMIT;
>
> If UPDATE2 fails because it, say, violates a foreign key constraint,
> then so be it. I want UPDATE3 to go ahead. Is this not possible, or is
> there an option I can use to do these kind of independent-query
> transactions?
That's not possible, by design.
However, your application could keep track of which queries have run, and
if one fails, start the transaction over without the failing query.
But the rule is, if any query within the transaction errors, then all queries
within the transaction are rolled back.
--
Bill Moran
http://www.potentialtech.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michal Paluchowski | 2007-08-14 18:04:30 | Creating a row during a select |
Previous Message | Phoenix Kiula | 2007-08-14 17:46:34 | Re: Moving to postgresql and some ignorant questions |