Emmanuel Cecchet <manu@asterdata.com> writes:
> Tom Lane wrote:
>> The key word in my sentence above is "arbitrary". You don't know what
>> a datatype input function might try to do, let alone triggers or other
>> functions that COPY might have to invoke. They might do things that
>> need to be cleaned up after, and subtransaction rollback is the only
>> mechanism we have for that.
> Is it possible to use the try/catch mechanism to detect errors and log
> them and only abort the command at the end of the processing?
No, I wouldn't trust that. The point here is that various backend
subsystems (eg, locks, buffers) might need to be cleaned up after an
error before they can be used further. It might look like it works,
until you stumble across the cases where it doesn't. An example of the
sort of situation I'm concerned about is somebody throwing an elog
while holding a buffer lock. If you try to keep processing and clean
up later, it will work fine ... until the day comes that the subsequent
processing chances to try to lock that same buffer again, and then the
backend will freeze up.
We've got twenty years worth of code development that assumes that
transaction abort will clean up anything that was left hanging when
an error was thrown. It was difficult enough getting that to work
for subtransaction abort as well as main transaction abort. It's
not happening for anything less than a subtransaction abort.
This approach is a good tradeoff most of the time: the code is simpler,
much more reliable, and faster in the normal case than it would be if
we tried to do post-error cleanup differently. Error-tolerant COPY
is going to pay for all that, but we're not revisiting the decision.
regards, tom lane