Re: Is there a way to run heap_insert() AFTER ExecInsertIndexTuples() ?

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: Bruno Wolff III <bruno(at)wolff(dot)to>, "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, Zoltan Boszormenyi <zboszor(at)dunaweb(dot)hu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Is there a way to run heap_insert() AFTER ExecInsertIndexTuples() ?
Date: 2007-03-03 00:45:21
Message-ID: 45E8C521.5090106@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruno Wolff III wrote:
> On Thu, Mar 01, 2007 at 11:26:23 +0100,
> "Florian G. Pflug" <fgp(at)phlo(dot)org> wrote:
>> But just postponing nextval() until after the uniqueness checks
>> only decreases the *probability* of non-monotonic values, and
>> *does not* preven them. Consindert two transactions
>>
>> A: begin ;
>> B: Begin ;
>> A: insert ... -- IDENTITY generates value 1
>> B: insert .. -- IDENTITY generates value 2
>> A: rollback ;
>> B: commit ;
>>
>> Now there is a record with IDENTITY 2, but not with 1. The *only*
>> way to fix this is to *not* use a sequence, but rather do
>> lock table t in exclusive mode ;
>> select max(identity)+1 from t ;
>> to generate the identity - but of course this prevents any concurrent
>> inserts, which will make this unuseable for any larger database.
>
> While this demonstrates that you can get holes in the sequence, it doesn't
> show an example that is not monotonic.
Sorry, my formulation was sloppy. What I meant is that you can't
guarantee gaplessness.

greetings, Florian Pflug

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message KaiGai Kohei 2007-03-03 01:25:38 Re: SE-Linux/PostgreSQL work?
Previous Message Andrew Dunstan 2007-03-03 00:42:14 Re: Arrays of Complex Types