Gurjeet Singh <singh.gurj...@gmail.com> writes:
> On Fri, Sep 24, 2010 at 11:15 PM, Robert Haas <robertmh...@gmail.com> wrote:
>> Hmm. So the problem is that we don't want to accidentally catch an
>> error that isn't actually safe to catch. We could probably mitigate
>> this problem to a considerable degree by throwing data validation
>> errors using some special flag that say "this is a recoverable error".
> Andrew suggested upthread:
> <snip>
> test_date := date_in(textout(some_text));
> In plpgsql you'd put that inside a begin/exception/end block that traps
> SQLSTATE '22000' which is the class covering data exceptions.
> </snip>
> In context of COPY, can we check for this SQLSTATE in PG_CATCH() and
> avoid PG_RE_THROW(). This would require that all type input functions call
> errcode() with proper MAKE_SQLSTATE() as part of ereport()/elog().
This is all pretty much a dead end, because it offers no confidence
whatsoever. Suppose that COPY calls type X's input function, which
calls function Y, which calls function Z. Z doesn't like what it sees
so it throws an error, which it marks "recoverable" since Z hasn't
done anything dangerous. Unfortunately, Y *did* do something that
requires cleanup. If COPY catches the longjmp and decides that it
can skip doing a transaction abort, you're screwed.
Again, the problem doesn't really arise as long as you're thinking about
simple code. You can fairly easily verify that no unsafe situation
arises so long as there's only one or two layers of functions involved.
But this approach just doesn't scale to anything complicated.
What I'm wondering is whether we can fix this by reducing the overhead
of subtransactions, enough so that we can afford to run each row's input
function calls within a subxact. In the past that was dismissed because
you'd run out of subxact XIDs at 4G rows. But we have "lazy" assignment
of XIDs now, so a subxact that didn't actually try to modify the
database shouldn't need to consume any permanent resources. Then we're
just looking at the time needed to call all the per-module subxact start
and subxact cleanup functions, which seems like something that might be
optimizable for the typical case where nothing actually needs to be
done.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
