Re: Timely reporting of COPY errors

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Postgresql <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Timely reporting of COPY errors
Date: 2008-06-23 22:42:38
Message-ID: 200806232242.m5NMgck18425@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Added to TODO:

o Allow COPY to report errors sooner

http://archives.postgresql.org/pgsql-hackers/2008-04/msg01169.php

---------------------------------------------------------------------------

Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> Hi,
>
> I notice that while doing bulk-loads that any errors detected by the
> backend arn't noticed by libpq until right at the end. Is this
> intentional? Looking at the code we have this comment in putCopyData:
>
> /*
> * Process any NOTICE or NOTIFY messages that might be pending in the
> * input buffer. Since the server might generate many notices during the
> * COPY, we want to clean those out reasonably promptly to prevent
> * indefinite expansion of the input buffer. (Note: the actual read of
> * input data into the input buffer happens down inside pqSendSome, but
> * it's not authorized to get rid of the data again.)
> */
>
> Except that pqSendSome won't try reading anything until it has a
> problem writing. Since the backend will consume copy data indefinitly,
> the error message sits in the kernel buffers until the end.
>
> Is there anything that can be done? I've tried putting in
> PQconsumeInput in places but it doesn't appear to help.
>
> Any ideas?
> --
> Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> > Please line up in a tree and maintain the heap invariant while
> > boarding. Thank you for flying nlogn airlines.
-- End of PGP section, PGP failed!

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2008-06-23 22:51:28 Re: [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout
Previous Message Mark Mielke 2008-06-23 22:41:46 Re: Dept of ugly hacks: eliminating padding space in system indexes