Re: COPY enhancements
От | Emmanuel Cecchet |
---|---|
Тема | Re: COPY enhancements |
Дата | |
Msg-id | 4ACCB787.3070207@asterdata.com обсуждение исходный текст |
Ответ на | Re: COPY enhancements (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: COPY enhancements
|
Список | pgsql-hackers |
Robert Haas wrote: > On Wed, Oct 7, 2009 at 11:39 AM, Emmanuel Cecchet <manu@asterdata.com> wrote: > >> Robert Haas wrote: >> >>> On Wed, Oct 7, 2009 at 9:12 AM, Emmanuel Cecchet <manu@asterdata.com> >>> wrote: >>> >>> >>>> Hi all, >>>> >>>> I think there is a misunderstanding about what the current patch is >>>> about. >>>> The patch includes 2 things: >>>> - error logging in a table for bad tuples in a COPY operation (see >>>> http://wiki.postgresql.org/wiki/Error_logging_in_COPY for an example; the >>>> error message, command and so on are automatically logged) >>>> - auto-partitioning in a hierarchy of child table if the COPY targets a >>>> parent table. >>>> The patch does NOT include: >>>> - logging errors into a file (a feature we can add later on (next commit >>>> fest?)) >>>> >>>> >>> My failure to have read the patch is showing here, but it seems to me >>> that error logging to a table could be problematic: if the transaction >>> aborts, we'll lose the log. If this is in fact a problem, we should >>> be implementing logging to a file (or stdout) FIRST. >>> >>> >> I don't think this is really a problem. You can always do a SELECT in the >> error table after the COPY operation if you want to diagnose what happened >> before the transaction rollbacks. >> > > Uhhh.... if the transaction has aborted, no new commands (including > SELECT) will be accepted until you roll back. > You are suggesting then that it is the COPY command that aborts the transaction. That would only happen if you had set a limit on the number of errors that you want to accept in a COPY command (in which case you know that there is something really wrong with your input file and you don't want the server to process that file). manu -- Emmanuel Cecchet Aster Data Systems Web: http://www.asterdata.com
В списке pgsql-hackers по дате отправления: