Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Hmm, if we were willing to break COPY into multiple *top level*
> transactions, that would avoid my concern about XID wraparound.
> The issue here is that if the COPY does eventually fail (and there
> will always be failure conditions, eg out of disk space), then some
> of the previously entered rows would still be there; but possibly
> not all of them, depending on whether we batch rows. The latter
> property actually bothers me more than the former, because it would
> expose an implementation detail to the user. Thoughts?
>
> Also, this does not work if you want the copy to be part of a bigger
> transaction, viz
> BEGIN;
> do something;
> COPY ...;
> do something else;
> COMMIT;
I was considering suggesting multiple top-level transactions, partly
based on the fact that other bulk-load utilities that I've used
support that. Then I realized that those were *client* side
applications, and didn't have to worry about being part of an
enclosing transaction. It seems wrong to break transactional
semantics in a single statement execution. Multiple top-level
transactions could be fine in a bulk-load *application*; but not, in
my view, in the COPY *statement*.
-Kevin