Greg Stark [EMAIL PROTECTED] writes:
I don't see how you're in the clear. If session A does an insert and it
doesn't see a duplicate and doesn't commit, but then B does an insert and sees
the duplicate from A and marks his tentative, and then commits, shouldn't B's
commit succeed?
No. B,
Alvaro Herrera [EMAIL PROTECTED] writes:
It's only a SMOC, nothing difficult AFAICS. Disk-spilling logic
included, because it'd be probably needed.
The question of disk-spilling is really the only part that seems very
hard. It would be useful to see if we could solve the problem of
spilling
George Essig [EMAIL PROTECTED] writes:
I noticed that implementing deferrable unique constraints is on the
TODO list. I don't think its been said yet, but currently you can
implement a deferrable unique constraint by using a deferrable
constraint trigger together with a procedural language
Greg Stark [EMAIL PROTECTED] writes:
Off the top of my head it seems the way to go about doing this would be to
simply not insert the records in the index until commit time. This doesn't
actually sound so hard, is there any problem with this approach?
Yeah:
begin;
insert into
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Off the top of my head it seems the way to go about doing this would be to
simply not insert the records in the index until commit time. This doesn't
actually sound so hard, is there any problem with this approach?
On Wed, 2005-01-26 at 15:48 -0500, Greg Stark wrote:
Well presumably you would need a non-unique index created for query execution
purposes. The unique index would be purely for enforcing the constraint.
Yuck.
You could perhaps relax the uniqueness of the index during the
transaction itself,
Neil Conway [EMAIL PROTECTED] writes:
You could perhaps relax the uniqueness of the index during the
transaction itself, and keep around some backend-local indication of
which index entries it have been inserted. Then at transaction-commit
you'd need to re-check the inserted index entries to
On Thu, Jan 27, 2005 at 03:31:29PM +1100, Neil Conway wrote:
You could perhaps relax the uniqueness of the index during the
transaction itself, and keep around some backend-local indication of
which index entries it have been inserted. Then at transaction-commit
you'd need to re-check the
Tom Lane [EMAIL PROTECTED] writes:
Yeah, what I've been visualizing is a list of tentative duplicates ---
that is, you do the immediate unique check same as now, and if it passes
(which hopefully is most of the time) then you're in the clear.
I don't see how you're in the clear. If session A
