Re: Best approach for a "gap-less" sequence

From: Jorge Godoy <jgodoy(at)gmail(dot)com>
To: Adrian Klaver <aklaver(at)comcast(dot)net>
Cc: pgsql-general(at)postgresql(dot)org, Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info>, Berend Tober <btober(at)seaworthysys(dot)com>, Jorge Godoy <jgodoy(at)gmail(dot)com>, Chris <dmagick(at)gmail(dot)com>
Subject: Re: Best approach for a "gap-less" sequence
Date: 2006-08-17 12:37:08
Message-ID: 87d5azilmz.fsf@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

elein <elein(at)varlena(dot)com> writes:

> If this is true the solution for a transactional, gapless sequence is possible
> for table.gl_id where updated from count.gl_id. It is simple. However, it
> *depends* on the fact that the second transaction getting the newly updated
> record from the first transaction. It seems pretty clear, not counting aggregates,
> that this is true from this doc snippet. Speak now, if someone doesn't read it
> this way! I'd like to understand why.

I agre with your reading.

> If it weren't true, there would also be a workaround which caught a duplicate
> value and tried again, looping.

This is true, but really bad. I believe a friend of mine had something like
that in another database server, but it really looked like an ugly hack... Of
course, if it's the only way to solve the problem then we have to live with
it.

> I may publish the gapless sequence technique on general bits if there is no
> discrepancy in the understanding of the status of the second transaction's
> row value (updated).

I need more testing here. But from what I tested, your reading looks right.

--
Jorge Godoy <jgodoy(at)gmail(dot)com>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jorge Godoy 2006-08-17 12:45:51 Re: Best approach for a "gap-less" sequence
Previous Message Jorge Godoy 2006-08-17 12:34:23 Re: Best approach for a "gap-less" sequence