Robert Haas wrote:
On Wed, Oct 7, 2009 at 11:39 AM, Emmanuel Cecchet <m...@asterdata.com> wrote:
Robert Haas wrote:
On Wed, Oct 7, 2009 at 9:12 AM, Emmanuel Cecchet <m...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
