Skip site navigation (1) Skip section navigation (2)

Re: Deferrable Unique Constraints

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>,pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Deferrable Unique Constraints
Date: 2005-01-27 04:42:44
Message-ID: 12329.1106800964@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Neil Conway <neilc(at)samurai(dot)com> 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 verify that they
> are unique.

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.
Otherwise you log the apparent duplicate key value to be rechecked at
commit.

> It would be nice to just keep a pin on the leaf page that we
> inserted into, although we'd need to take care to follow subsequent page
> splits (could we use the existing L & Y techniques to do this?).

I do not believe we can do that without risking deadlocks.  It'll be
safer just to repeat the search for each key value that's of concern.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2005-01-27 04:47:43
Subject: Re: Deferrable Unique Constraints
Previous:From: Neil ConwayDate: 2005-01-27 04:31:29
Subject: Re: Deferrable Unique Constraints

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group