Tom Lane <t...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
