Re: Replaceing records

From: Richard Ellis <rellis9(at)yahoo(dot)com>
To: PgSQL General ML <pgsql-general(at)postgresql(dot)org>
Subject: Re: Replaceing records
Date: 2003-09-04 22:00:47
Message-ID: 20030904220046.GA30806@i386.dp100.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Sep 04, 2003 at 12:29:17PM -0700, Stephan Szabo wrote:
>
> On Thu, 4 Sep 2003, Richard Ellis wrote:
>
> > On Thu, Sep 04, 2003 at 12:17:35PM +0200, Csaba Nagy wrote:
> > > [philosophical post regarding a missing feature of Postgres]
> > >
> > > I found there's no way to avoid failed inserts because of
> > > unique constraint violations, causing automatic roll-back of
> > > the running transaction.
> > >
> > > Now contention on insert has a quite high probability for this
> > > operation in our application.
> >
> > Did you ever try this:
> >
> > insert into test (a, b, c, d)
> > (select 1, 2, 3, 4 where not exists
> > (select 1 from test where a=1 and b=2 and c=3 and d=4)
> > );
> >
> > If your table contains a=1, b=2, c=3, and d=4, nothing will
> > happen, and there will be no failed transaction. If your table
> > does not contain a=1, b=2, c=3, and d=4, you'll get an insert of
> > a row containing 1, 2, 3, 4.
>
> Unfortunately that doesn't work if two transactions want to insert
> a row containing 1,2,3,4 that are running concurrently.

True, if the row does not already exist. But in that situation,
because of the unique constraint premise in the original quote, there
is always going to be at least one failed transaction. So the battle
is already lost before it's even begun.

If, however, the same row already exists in the table, then both of these
inserts will silently do nothing, and both transactions will continue
without aborting.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ron Johnson 2003-09-04 22:23:30 Re: Backup?
Previous Message Henrique Lima 2003-09-04 21:54:08 Inquiry From Form [pgsql]