| From: | Holger Jakobs <holger(at)jakobs(dot)com> |
|---|---|
| To: | pgsql-admin(at)lists(dot)postgresql(dot)org |
| Subject: | Re: ERROR : invalid transaction termination : PostgreSQL v12 |
| Date: | 2020-11-24 21:15:15 |
| Message-ID: | 783165ad-62f6-dad9-6aa9-814428e49743@jakobs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
So what is the intended behaviour?
* If you run everything in autocommit, it will be very slow, but all
non-failing records will end up in the table alright.
* If you run a commit after a couple of records, you will lose all
records of this group if there is at least one failing record.
is that what you want?
Oracle's behaviour of saving all non-failing records while discarding
all failing records is not directly possible with PostgreSQL, because
the sense of a transaction is all-or-nothing.
Am 24.11.20 um 16:39 schrieb David G. Johnston:
> On Tue, Nov 24, 2020 at 12:57 AM Holger Jakobs <holger(at)jakobs(dot)com
> <mailto:holger(at)jakobs(dot)com>> wrote:
>
> What is the point of COMMITting after a few records? Why not let
> the whole batch run through. If there are any errors, PostgreSQL
> will rollback the whole transaction anyway.
>
> Avoiding that behavior is the point of batching with periodic commits.
>
> David J.
>
--
Holger Jakobs, Bergisch Gladbach, Tel. +49-178-9759012
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-11-24 21:21:34 | Re: ERROR : invalid transaction termination : PostgreSQL v12 |
| Previous Message | Laurenz Albe | 2020-11-24 16:05:29 | Re: Streaming Replication replay lag |