Re: Practical error logging for very large COPY

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Practical error logging for very large COPY
Date: 2005-11-22 09:22:44
Message-ID: 1132651364.4959.578.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2005-11-21 at 19:05 -0500, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > Flow of control would be to:
>
> > locate page of index where value should go
> > lock index block
> > _bt_check_unique, but don't error
> > if violation then insert row into ERRORTABLE
> > else
> > insert row into data block
> > insert row into unique index
> > unlock index block
> > do other indexes
>
> Ugh. Do you realize how many levels of modularity violation are implied
> by that sketch?

IMHO the above is fairly ugly, but I suggest it now because:
1. I want to avoid uniqueness violations in COPY
2. The logic used is very similar to that recently proposed for MERGE.

If anybody has a better idea for (1), shout it out now.

If the logic is OK for MERGE, then it should be OK for COPY with
uniqeness violation trapping also. Both use uniqueness checking first,
so you'd need to argue against both or neither.

> Have you even thought about the fact that we have more
> than one kind of index?

Yes, but they don't support unique indexes do they?

Best Regards, Simon Riggs

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message gevik 2005-11-22 09:57:19 TODO item "%Allow pg_hba.conf be controlled via SQL"
Previous Message Simon Riggs 2005-11-22 09:21:26 Re: Practical error logging for very large COPY