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