| From: | Emmanuel Cecchet <manu(at)asterdata(dot)com> |
|---|---|
| To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
| Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Emmanuel Cecchet <manu(at)asterdata(dot)com>, Selena Deckelmann <selenamarie(at)gmail(dot)com>, Emmanuel Cecchet <Emmanuel(dot)Cecchet(at)asterdata(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: COPY enhancements |
| Date: | 2009-10-07 15:50:05 |
| Message-ID: | 4ACCB8AD.2010803@asterdata.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Smith wrote:
> Absolutely, that's the whole point of logging to a file in the first
> place. What needs to happen here is that when one is aborted, you
> need to make sure that fact is logged, and with enough information
> (the pid?) to tie it to the COPY that failed. Then someone can crawl
> the logs to figure out what happened and what data did and didn't get
> loaded. Ideally you'd want to have that as database table information
> instead, to allow automated recovery and re-commit in the cases where
> the error wasn't inherent in the data but instead some other type of
> database failure.
If one is aborted, nothing gets loaded anyway. Now if you want a
separate log of the successful commands, I don't think that should apply
just to COPY but to any operation (insert, update, DDL, ...) if you want
to build some automatic retry mechanism. But this seems independent from
COPY to me.
manu
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Fetter | 2009-10-07 16:17:52 | Concurrency testing |
| Previous Message | Emmanuel Cecchet | 2009-10-07 15:45:11 | Re: COPY enhancements |