Horton

Re: VLDB Features

Nikhils <nikkhils@gmail.com>

View thread
From: NikhilS <nikkhils@gmail.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Neil Conway" <neilc@samurai.com>, "Hannu Krosing" <hannu@skype.net>, "Josh Berkus" <josh@agliodbs.com>, pgsql-hackers@postgresql.org, "Simon Riggs" <simon@2ndquadrant.com>
Date: 2007-12-17T07:35:35Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. doc: Fix COPY ON_ERROR option syntax synopsis.

  2. Disallow specifying ON_ERROR option without value.

  3. Rename COPY option from SAVE_ERROR_TO to ON_ERROR

  4. Fix spelling in notice

  5. Add new COPY option SAVE_ERROR_TO

Hi,

On Dec 15, 2007 1:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> NikhilS <nikkhils@gmail.com> writes:
> > Any errors which occur before doing the heap_insert should not require
> > any recovery according to me.
>
> A sufficient (though far from all-encompassing) rejoinder to that is
> "triggers and CHECK constraints can do anything".
>
> > The overhead of having a subtransaction per row is a very valid concern.
> But
> > instead of using a per insert or a batch insert substraction, I am
> > thinking that we can start off a subtraction and continue it till we
> > encounter a failure.The moment an error is encountered, since we have
> the offending >(already in heap) tuple around, we can call a
> simple_heap_delete on the same and commit >(instead of aborting) this
> subtransaction
>
> What of failures that occur only at (sub)transaction commit, such as
> foreign key checks?
>

What if we identify and define a subset where we could do subtransactions
based COPY? The following could be supported:

* A subset of triggers and CHECK constraints which do not move the tuple
around. (Identifying this subset might be an issue though?)
* Primary/unique key indexes

As Hannu mentioned elsewhere in this thread, there should not be very many
instances of complex triggers/CHECKs around? And  may be in those instances
(and also the foreign key checks case), the behaviour could default to use a
per-subtransaction-per-row or even the existing single transaction model?

Regards,
Nikhils
-- 
EnterpriseDB               http://www.enterprisedb.com